Node.js Error Handling

Node.js Error Handling – ERR_ASYNC_TYPE

The number of possible Node.js errors is extensive, so today we continue our detailed Node.js Error Handling series by looking at one of the many System Errors-categorized errors called ERR_ASYNC_TYPE. Node throws a System Error when an exception occurs within the program’s runtime environment, and such errors are typically an indication that there was an operational problem within the application. An ERR_ASYNC_TYPE error indicates that an attempt was made to pass an invalid data type to the AsyncResource class constructor.

Throughout this article we’ll explore the ERR_ASYNC_TYPE system error by looking at where it sits in the overall Node.js Error Class Hierarchy. We’ll also examine the basics of using the AsyncResource class, and how passing invalid arguments might result in ERR_ASYNC_TYPEs, so let’s get to it!

The Technical Rundown

Most Node.js errors inherit from the Error base class, or extend from an inherited class therein. The full error hierarchy of this error is:

Full Code Sample

Below is the full code sample we’ll be using in this article. It can be copied and pasted if you’d like to play with the code yourself and see how everything works.

When Should You Use It?

As some readers may recall we explored the Node.js ERR_ASYNC_CALLBACK error in an article last week, which was similar to the ERR_ASYNC_TYPE error, except the ERR_ASYNC_CALLBACK error indicated an invalid data type used as async_hook callback arguments. On the other hand, the ERR_ASYNC_TYPE error is a result of using the AsyncResource class constructor and passing an invalid type parameter. To illustrate this difference we’ll start with a simple code sample that creates a new AsyncResource instance, uses it in conjunction with a basic net module server instance to connect to localhost:8080 and send a message:

The typical usage of AsyncResource is to extend it with your own class (e.g. class MyAsyncObject extends AsyncResource { ... }), but for our simple example we’re just directly invoking the callback emitters, such as emitBefore(). Each of these emitters invokes all associated callbacks, which means the emitBefore() method invokes all before callbacks.

We’ll test out our getAsyncResource(options) function with a handful of tests, each of which passes a different set of values into the AsyncResource(...) constructor:

Executing the first of these tests works as expected and produces the following output:

Our net server is created and connects, then performs its basic process of sending a SERVER ACCEPTING CONNECTIONS message after a 1-second delay. We also retrieve the asyncId and triggerAsyncId values from the AsyncResource instance, before eventually closing the connection after 2 more seconds and invoking resource.emitDestroy().

The 'MyNetResource' string is the type argument passed into AsyncResource, so what happens if we pass a numeric value like 24601 as seen in our second test? We’re presented with an error, though not the ERR_ASYNC_TYPE, but an ERR_INVALID_ARG_TYPE instead, indicating that the type argument must be a string:

Alright, so our last test passes an empty string as the type argument, which produces the following output:

Here we see an ERR_ASYNC_TYPE error, which illustrates an interesting and subtle difference between what type of parameters the AsyncResource constructor expects — since anything that isn’t a string throws an ERR_INVALID_ARG_TYPE, the only scenario in which an ERR_ASYNC_TYPE error is (currently) thrown is when passing an empty string. The reason for this result can be seen by digging into the Node.js source code a bit within the async_hooks.js files:

Here we can see that the AsyncResource constructor calls the emitInit(...) method, which is retrieved from internal/async_hooks.js at the top of the file:

The internal/async_hooks.js module exports the local emitInitScript function as emitInit:

Finally, looking at the emitInitScript function shows where the ERR_ASYNC_TYPE error is coming from. If type != 'string' or the length is less than or equal to zero, a new ERR_ASYNC_TYPE err is thrown.

Airbrake’s robust error monitoring software provides real-time error monitoring and automatic error reporting for all your development projects. Airbrake’s state of the art web dashboard ensures you receive round-the-clock status updates on your application’s health and error rates. No matter what you’re working on, Airbrake easily integrates with all the most popular languages and frameworks. Plus, Airbrake makes it easy to customize error parameters, while giving you complete control of the active error filter system, so you only gather the errors that matter most.

Check out Airbrake’s error monitoring software today and see for yourself why so many of the world’s best engineering teams use Airbrake to revolutionize their exception handling practices!