Why classic stacktraces are not very helpful when dealing with async functions
Look at this example. one
calls two
, two
calls three
, and three
calls four
. All functions call the given callback asynchronous. four
calls the callback with an error. three
and two
passes the error to their callback function and stop executing with return
. one
finally throws it
{ ;} { ;} { ;} { ;} ;
When you execute it, you will get this:
$ node example_without.js
/home/pita/Code/async-stacktrace/example_without.js:5
throw err;
^
Error
at Timer.callback (/home/pita/Code/async-stacktrace/example_without.js:47:14)
The problems here are:
- You can see that the error happend in
four
, but you can't see from wherefour
was called. The context gets lost - You write the same 4 lines over and over again, just to handle errors
The solution
two
and three
Lets replace this code in iferr ; return;
with
if return;
one
and replace this code in iferr throw err;
with
;
This is how it looks like now:
var ERR = ; { ;} { ;} { ;} { ;} ;
When you execute it, you will get this:
$ node example.js
/home/pita/Code/async-stacktrace/ERR.js:57
throw err;
^
Async Stacktrace:
at /home/pita/Code/async-stacktrace/example.js:6:6
at /home/pita/Code/async-stacktrace/example.js:17:10
at /home/pita/Code/async-stacktrace/example.js:30:10
Error
at Timer.callback (/home/pita/Code/async-stacktrace/example.js:41:14)
What is new?
The "Async Stacktrace" shows you where this error was caught and passed to the next callback. This allows you to see from where four
was called. You also have less code to write
npm
npm install async-stacktrace
Usage
This is how you require the ERR function
var ERR = ;
The parameters of ERR()
are:
err
The error object (can be a string that describes the error too)callback
(optional) If the callback is set and an error is passed, it will call the callback with the modified stacktrace. Else it will throw the error
The return value is true if there is an error. Else its false