The Right Tool for the Way the Job Will Probably Go Wrong

Title

Description

Handling errors in asynchronous code is hard. Without correct handling, failures often manifest as errors far from the actual problem with little information about what really went wrong. Even worse, it’s far too easy to write Node programs that fail silently where other languages would explode with show-stopping exceptions. Don’t settle for if (err) throw err! Node and JavaScript itself offer a range of ways to write asynchronous code (callbacks, events, streams, promises…) and all of them have their own unique flavor of effective and elegant error handling.

There’s no one right way to write asynchronous code but the tools each provides for dealing with exceptions should be a key consideration in which to pick. Like many things, that always depends on the particular case. The difference here is in shifting perspective from thinking mainly about what a program is intended to do to how it might fail. This talk will explore what that means and make an argument about which approach fits best with different types of challenge.

Learning objectives

Different async styles differ significantly in how they handle errors and this has real consequences for what constitutes robust design. Attendees will learn the most dangerous pitfalls and how to avoid them.
Each error handling style has advantages and disadvantages for dealing with different types of programming challenge. Attendees will learn both the speaker’s opinion of how the comparison shakes out in some key examples and what factors to consider when weighing the options for themselves.
Attendees will be prompted to consider the larger question of how Node’s fundamentally asynchronous nature forces us to think differently about failure than we might when working in another language.
City of residence

New York, United States

nodeconf / budapest