I'm developing a backend app in Node.js and I came across with following problem: When developer call promise function like below:
mainRouter.get("/xD", async (req, res) => {
res.send(await this.fooService.foo());
});
there is possibility that this.fooService.foo() function will fail (promise rejection) and the end user will get request timeout.
I want to be sure that developer mistake will not cause UnhandledPromiseRejectionWarning (and finally timeout error). The question is how to configure app to log errors and return status 500 to user when UnhandleRejection occurs.
What I tried:
mainRouter.get("/xD", async (req, res) => {
try {
res.send(await this.fooService.foo());
} catch (err) {
res.status(500).send("error");
}
});
Above code will do the thing but it requiers from developer to write above code in every route, so it's not quite a clean solution.
I also tried to use error middleware:
mainRouter.use((err:any, req, res, next) => {
console.log(err);
res.status(500).send("Error");
});
but it doesn't catch PromiseRejection
Finally I created middleware which registers function handler for unhandledRecejtion event:
mainRouter.use((req, res, next) => {
process.on('unhandledRejection', (reason, p) => {
console.log(reason);
res.status(500).send("Error");
});
next();
});
I'm not sure how process events works in node.js but I'm afraid that the code above will cause problems for scenario:
First request generates unhandled promise rejection
The newest request which registered handler last, will return to user status 500.
Why not just provide a wrapper function that everyone could use
async function wrapAsync(res, asyncFn) {
try {
res.send(await asyncFn());
} catch (err) {
res.status(500).send("error");
}
}
where asyncFn is a function that returns a promise
Then other developers can simply use it this way
mainRouter.get("/xD", async (req, res) => await wrapAsync(res, this.fooService.foo));
It may also be possible to overwrite mainRouter.get and provide an even shorter abstraction
Related
I have a problem with an error appearing on one of my express route. I handled it by using express next but then the error is also caught by my global process.on('uncaughtException') that is implemented to shut-down my server. Hope this example is clear.
app.get("/api/users", async (req, res, next) => {
try {
// (1) This call will throw an error
const users = await getUsers()
res.send(users)
}
catch (err) {
// (2) The error will be correctly caught by this try catch and send to the error handler
next(err)
}
})
// (3) The problem is that it will be also caught by this and my server will stop
// I don't want this since I've already handled it using express
process.on('uncaughtException', (err: Error) => cleanShutdown(`Uncaught exception`, err))
Is it possible to avoid going to (3) when I have already handled the error?
i tried to find a solution for this warning i get, but none of the suggested approaches worked for me. I don't want to disable this warning, because i believe this warning is there for a reason, but i can't figure out whats the real deal here.
I have the following route defined on my node.js server running express:
// GET all items
router.get('', helpers.loginRequired, function(req, res) {
debug("Get all items");
return knex.select('*').from('routes')
.then((routes) => {
res.send(routes);
return null;
})
.catch((err) => {
debug("error getting routes");
res.send({ error: "Fehler beim Laden" });
return null;
});
});
My Middleware loginRequired does not use any promise at all
function loginRequired(req, res, next) {
if (!req.user) {
req.flash('loginMessage', 'Du musst eingeloggt sein!');
req.session.redirectTo = req.path;
return res.redirect('/');
} else {
return next();
}
}
I use knex for accessing my database, which creates promises.
And everytime i hit the route, i get the following warning:
(node:10568) Warning: a promise was created in a handler but was not returned fr
om it, see *link*
at Function.Promise.attempt.Promise.try (C:\Users\qxr1088\Desktop\Privat\GPS
\bibis-tracker\node_modules\bluebird\js\release\method.js:29:9)
As you can see i tried to add the "return null;" statements as suggested by bluebird, but this does not fix the problem.
These two middleware functions behave differently and I cannot figure out why:
Here, the error will get trapped by try/catch:
router.get('/force_async_error/0', async function (req, res, next) {
try{
await Promise.reject(new Error('my zoom 0'));
}
catch(err){
next(err);
}
});
But here, the error will not get trapped by try/catch:
router.get('/force_async_error/1', async function (req, res, next) {
await Promise.reject(new Error('my zoom 1'));
});
I thought Express wrapped all middleware functions with try/catch, so I don't see how it would behave differently?
I looked into the Express source, and the handler looks like:
Layer.prototype.handle_request = function handle(req, res, next) {
var fn = this.handle;
if (fn.length > 3) {
// not a standard request handler
return next();
}
try {
fn(req, res, next); // shouldn't this trap the async/await error?
} catch (err) {
next(err);
}
};
so why doesn't the try/catch there capture the thrown error?
I'm going to add an answer here even though you've already accepted another one because I think what's going on here can be explained better and this will help others attempting to understand this.
In your code here:
router.get('/force_async_error/1', async function (req, res, next) {
await Promise.reject(new Error('my zoom 1'));
});
Let's discuss what is going on:
First, you declared the callback as async which you had to do in order to use await in it. An async function tells the interpreter to do several important things.
1. An async function always returns a promise. The resolved value of the promise will be whatever the function returns.
2. An async function is internally wrapped with a try/catch. If any exceptions are thrown in the top level scope of the function code, then those exceptions will be caught and will automatically reject the promise that the function returns.
3. An async function allows you to use await. This is an indicator to the interpreter that it should implement and allow the await syntax inside the function. This is tied to the previous two points above which is why you can't use await in just any 'ol function. Any uncaught rejections from await will also reject the promise that the function returns.
It's important to understand that while the async/await syntax allows you to kind of program with exceptions and try/catch like synchronous code, it isn't exactly the same thing. The function is still returning a promise immediately and uncaught exceptions in the function cause that promise to get rejected at some time later. They don't cause a synchronous exception to bubble up to the caller. So, the Express try/catch won't see a synchronous exception.
But here, the error will not get trapped by try/catch
I thought Express wrapped all middleware functions with try/catch, so I don't see how it would behave differently?
so why doesn't the try/catch [in Express] there capture the thrown error?
This is for two reasons:
The rejected promise is not a synchronous throw so there's no way for Express to catch it with a try/catch. The function just returns a rejected promise.
Express is not looking at the return value of the route handler callback at all (you can see that in the Express code you show). So, the fact that your async function returns a promise which is later rejected is just completely ignored by Express. It just does this fn(req, res, next); and does not pay attention to the returned promise. Thus the rejection of the promise falls on deaf ears.
There is a somewhat Express-like framework called Koa that uses promises a lot and does pay attention to returned promises and which would see your rejected promise. But, that's not what Express does.
If you wanted some Koa-type functionality in Express, you could implement it yourself. In order to leave other functionality undisturbed so it can work normally, I'll implement a new method called getAsync that does use promises:
router.getAsync = function(...args) {
let fn = args.pop();
// replace route with our own route wrapper
args.push(function(req, res, next) {
let p = fn(req, res, next);
// if it looks like a promise was returned here
if (p && typeof p.catch === "function") {
p.catch(err => {
next(err);
});
}
});
return router.get(...args);
}
You could then do this:
router.getAsync('/force_async_error/1', async function (req, res, next) {
await Promise.reject(new Error('my zoom 1'));
});
And, it would properly call next(err) with your error.
Or, your code could even just be this:
router.getAsync('/force_async_error/1', function (req, res, next) {
return Promise.reject(new Error('my zoom 1'));
});
P.S. In a full implementation, you'd probably make async versions of a bunch of the verbs and you'd implement it for middleware and you'd put it on the router prototype. But, this example is to show you how that could work, not to do a full implementation here.
This is because the call is asynchronous, take this code :
try {
console.log('Before setTimeout')
setTimeout(() => {
throw new Error('Oups')
})
console.log('After setTimeout')
}
catch(err) {
console.log('Caught', err)
}
console.log("Point of non-return, I can't handle anything anymore")
If you run it you should see that the error is triggered after Point of non-return.
When we're at the throw line it's too late, we're outside of try/catch. At this moment if an error is thrown it'll be uncaught.
You can work around this by using async/await in the caller (doesn't matter for the callee), ie :
void async function () {
try {
console.log('Before setTimeout')
await new Promise((resolve, reject) =>
setTimeout(() => {
reject(new Error('Oups'))
})
)
console.log('After setTimeout')
}
catch(err) {
console.log('Caught', err.stack)
}
console.log("Point of non-return, I can't handle anything anymore")
}()
Finally, this means that for Express to handle async errors you would need to change the code to :
async function handle(req, res, next) {
// [...]
try {
await fn(req, res, next); // shouldn't this trap the async/await error?
} catch (err) {
next(err);
}
}
A better workaround:
Define a wrap function like this :
const wrap = fn => (...args) => Promise
.resolve(fn(...args))
.catch(args[2])
And use it like this :
app.get('/', wrap(async () => {
await Promise.reject('It crashes!')
}))
Neither of these really answer the question, which if I understand correctly is:
Since the async/await syntax lets you handle rejected "awaits" with non-async style try/catch syntax, why doesn't a failed "await" get handled by Express' try/catch at the top level and turned into a 500 for you?
I believe the answer is that whatever function in the Express internals that calls you would also have to be declared with "async" and invoke your handler with "await" to enable async-catching try/catch to work at that level.
Wonder if there's a feature request for the Express team? All they'd need to add is two keywords in two places. If success, do nothing, if exception hand off to the error handling stack.
Beware that if you don't await or return the promise, it has nothing to do with express - it just crashes the whole process.
For a general solution for detached promise rejections:
https://stackoverflow.com/a/28709667
Copied from above answer:
process.on("unhandledRejection", function(reason, p){
console.log("Unhandled", reason, p); // log all your errors, "unsuppressing" them.
//throw reason; // optional, in case you want to treat these as errors
});
I'm starting out w/ NodeJS and Express. Coming from the other popular scripting languages and C++ background, asynchronously calling DB functions is a bit foreign. I've sorted out a pattern, but I'm still curious about catching exceptions. Below is my basic pattern.
var callback = function(req, res) {
// do stuff
connection.query(queryString, function(err,result){
if (err) throw err;
// process results.
};
};
var express = require('express');
var app = express();
app.get('/', callback);
app.listen(3000,function() {
console.log('listening');
};
Generally I have a lot of endpoints and callbacks. I'm a bit lost on where I set up ta try/catch block to catch errors thrown in the callback though. I've looked around for some suggestions, but a lot of them seem to be on the web framework (if any) being used.
When you throw in an asynchronous callback, the exception just goes back to the internals of the database event handler and there is NO way for you to ever catch or handle that exception. So, basically it does no good at all. It will just cause you to abort the handling of that request and you will never send a response on that request.
Basically, you have several choices for how to handle the error. You can handle it completely right in each endpoint and send some sort of error response.
Send Response right at each point of error
app.get('/', function(req, res) {
// do stuff
connection.query(queryString, function(err,result){
if (err) return res.status(500).send(someErrorResponse);
// process results.
};
});
Forward on to centralized error handler
Or, you can forward the error on to a centralized error handler by calling next(err):
app.get('/', function(req, res, next) {
// do stuff
connection.query(queryString, function(err,result){
// if error, forward it on to our centralized error handler
if (err) return next(err);
// process results.
};
});
// centralized error handler - note how it has four parameters
app.use(function(err, req, res, next) {
// formulate an error response here
console.log(err);
res.status(500).send(someErrorMessage)
});
See Nodejs handle unsupported URLs and request types for more info on the ways to have generalized error handlers in Express.
Use promises to collect errors within each route
If you are using more involved sequences of asynchronous operations where you may have more than one async operation sequenced together, then it does get to be a pain to handle errors at every single async operation. This is where using promises with all your async operations more easily allows all the errors to percolate up to one .catch() statement at the top level of each route. You don't say what database you're using, but here's an idea what that looks like. The general idea is that you can write your code so that all promise rejections (e.g. errors) will propagate up to one central .catch() in each route handler and you can then call next(err) from that .catch(), sending the error to your centralized error handler. Here's how that looks for a recent version of Mongoose (you didn't say which database you were using) with one database operation.
app.get('/', function(req, res, next) {
// do stuff
connection.query(queryString).exec().then(function(result){
// process results.
}).catch(next);
});
// centralized error handler - note how it has four parameters
app.use(function(err, req, res, next) {
// formulate an error response here
console.log(err);
res.status(500).send(someErrorMessage)
});
And, here's what it looks like if you have more than one operation:
app.get('/', function(req, res, next) {
// do stuff
connection.query(queryString).exec().then(function(result){
// process results, then make another query
// return the promise from this second operaton so both results
// and error are chained to the first promise
return connection.query(...).exec();
}).then(function(result) {
// process chained result
}).catch(next);
});
// centralized error handler - note how it has four parameters
app.use(function(err, req, res, next) {
// formulate an error response here
console.log(err);
res.status(500).send(someErrorMessage)
});
Since ES6 built in support for promises and ES7 will add support for async/await for asynchronous operations (which is based on promises) and all significant libraries that offer asynchronous operations have added or are adding support for promises, it is clear that promises are the future of the language for managing asynchronous operations. That would be my strong recommendation.
You should never, ever throw an error like that! :) The reason is that at some point your whole node app will just stop working, because of some db query failed. This should be handled instead of just die.
And because this is a route handler - handles specific url that the user is getting (for example /), there should be some output. You can always show a page with status 500 and a nice design, if there was such an error that you cannot handle or you might have your internal state messed up.
So basically just act as nothing happened - return respones of any kind, or even render a page, but provide information that something went wrong.
Also, a common scenario is something like what Alon Oz presented. All routes in express are actually a middleware functions, that are called one after another. If the route does not match the requested one, the function just skips and the next one is called. You can manually control that. The actual pattern of the router is this:
app.get('/', function(req, res, next) {
// you can have the request
// you can send response like res.send('hello')
// OR you can skip this function using NEXT
});
The actual signature of next is next(err). So if you call it without any arguments, it will just skip to the next middleware. If you call it with an argument, it will skip all regular functions and go to the last ones in the stack, or more specifically the ones that handle errors. They are like the regular ones, but taking four arguments instead of three:
app.use(function (err, req, res, next) { });
It's very important to understand that this function will be called if you call next with an argument. Throwing an error won't do any good! Of course if none of your routes match the specific criteria (url) the final one will in the call will be called, so you can still handle the "not found" error.
This is a common scenario that you will use:
// development error handler, will print stacktrace
if (app.get('env') === 'development') {
app.use(function(err, req, res, next) {
debug('ERROR [ip: %s]:: dev env -> ', req.ip, err); // I'm using debug library - very helpful
res.status(err.status || 500);
res.render('deverr', { // I render custom template with the whole stack beautifully displayed
errMessage: err.message,
error: err
});
});
}
// production error handler, no stacktraces leaked to user
app.use(function(err, req, res, next) {
res.status(err.status || 500);
res.render('pages/error', { // custom error page with nice design and a message
errMessage: err.message,
error: {}
});
});
Hope that helps! :)
Since you are using express, it has its own way to handle exceptions,
defined like this:
function clientErrorHandler (err, req, res, next) {
if (req.xhr) {
res.status(500).send({ error: 'Something failed!' })
} else {
next(err)
}
}
app.use(clientErrorHandler)
For more info:
https://expressjs.com/en/guide/error-handling.html
There are most commonly three major types of errors that we need to take into account.
Promise failures (Any failures that come up during async/await or result of a promise in then/catch)
In order to handle promise failures, as suggested in the strong loop document or node js 2018 best practices, it's important to have a common function that can handle it.
// app.js file
app.get('/:id', async (req,res,next) => {
if(!req.params.id) {
return res.status(412).send('enter a valid user id');
}
try {
const results = await UserDAL(id);
} catch(e) {
next(e);
}
}
// common error middleware defined in middleware/error.js
module.exports = function (err,req,res,next) {
logger.error(`${err.status || 500} - ${err.message} - ${req.originalUrl} - ${req.method} - ${req.ip}`);
return res.status(500).send('something failed.');
};
Unhandled Rejections
process.on('unhandledRejection', e => {
// do something
});
Unhandled exceptions
process.on('uncaughtException', e => {
// do something
});
If you see a lot of try/ catch blocks in your express methods you can abstract that to a separate async function like below:
module.exports = function asyncMiddleWare(handler) {
return async (req,res,next) => {
try {
await handler(req,res)
} catch(e) {
next(e);
}
}
};
The following question is asked in order to better understand from your answers how to think "Async" when developing on Node.js
I have the following code:
router.get('/', function(req, res, next) {
... //Definition of rules and paramsObj
//Validation that returns a promise
Indicative.validate(rules,paramsObj)
.then(function(success){
//we passed the validation. start processing the request
//ProcessRequest has async calls but when all async functions are over, it sets paramObj.someVal with a calculated value.
processRequest(paramsObj,next);
//My problem is here. at this point paramsObj.someVal is not set yet. and therefore the response to the user will be incorrect.
res.send(paramsObj.someVal);
}).catch(function(err){
console.log(err);
next(err);
}).done();
}
I wish to understand how to better think "async" while i need to wait with the response to the user until all async functions are over.
My question is how to execute res.send(paramObj.someVal) only after the paramObj.someVal is set by some async methods in processRequest(paramsObj,next);
If you need to wait on the result of processRequest for paramsObj.someVal to be set then ultimately you need to handle that callback
router.get('/', function(req, res, next) {
... //Definition of rules and paramsObj
//Validation that returns a promise
Indicative.validate(rules,paramsObj)
.then(function(success){
//we passed the validation. start processing the request
//ProcessRequest has async calls but when all async functions are over, it sets paramObj.someVal with a calculated value.
processRequest(paramsObj, function(err) {
if (!err && !paramsObj.someVal) {
// raise a custom error if the value is not set
err = new Error('Value not set');
}
if (err) {
next(err);
} else {
res.send(paramsObj.someVal);
}
});
}).catch(function(err){
console.log(err);
next(err);
}).done();
}
Assuming the second argument to processRequest() is a completion callback, you can pass your own function for that callback and do your res.send() in that custom callback like this:
router.get('/', function(req, res, next) {
... //Definition of rules and paramsObj
//Validation that returns a promise
Indicative.validate(rules,paramsObj)
.then(function(success){
//we passed the validation. start processing the request
//ProcessRequest has async calls but when all async functions are over, it sets paramObj.someVal with a calculated value.
processRequest(paramsObj,function() {
res.send(paramsObj.someVal);
});
}).catch(function(err){
console.log(err);
next(err);
}).done();
}
Since you do res.send(...), I assume you don't want to actually call next() in that code path.