expressjs / expressjs/express

Zone.js for async error handling

Open
#4,186 9 comments 0 reactions 0 assignees View on GitHub
discuss
Dominant language
JavaScript
Stars
69.5k
Forks
25k
Avg merge
4d 20h
Merged PRs (30d)
9

Description

Currently when i create a new express application.
That application has a default error handling.
So code like this:

```
const express = require("express");

const app = express();

app.get("*", function() {
throw new Error("something happened");
})

app.listen(3000, function() {
console.log("we are now listening to port 3000");
});
```

Will cause the default express error handler to kick in.
The js process does not crash and everything works as expected.

For async error the behaviour is different and my question is why?
with **Zone.js** we can now do a similar behaviour.
For example:

```
const express = require("express");

const app = express();

app.get("*", function() {
setTimeout(() => {
throw new Error("something happened");
}, 500);
})

app.listen(3000, function() {
console.log("we are now listening to port 3000");
});
```

the above code will crash the process.

According to express docs.
we can handle sync error but the async error you will have to call **next** with the error.
So the above code should be like so:

```
app.get("*", function(req, res, next) {
setTimeout(() => {
next(new Error("something happened"));
}, 500);
})
```

So this behaviour seems non ideal to me, cause in my opinion, with **zone.js** in the picture we can reach a much better results.
I would love to open a discussion on the matter...
The ideal is similar behaviour with sync and async errors (which is quite possible with zone.js to identify error that originate from async code inside express middleware functions).
so to summarise I would see the async error handling working like this:
- if we are using next(new Error()) then great let's keep the same behaviour.
- if not, determine with zone.js if we have exception in our async code that originated from one of our middleware functions, and pop the default error handler (and of course the process will not crash).
- This will result in much stable apps (process won't be close on async errors) and another added bonus is better debugging, and better error messages and stack traces of the exceptions in our async code.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.