defaut error handler (finalhandler) should not prevent the response being sent

Problem

Or else there should be an option to provide a custom made final handler. Why: I use 2 error handlers in my app : one that logs the error in our database, and one that returns a 500 to the client, with an particular error message. If for any reason I have two bits of async code that both rise an error, the app just throws the 2nd error to stderr and don't return anything (not even the first 500) to the client. So the bug is : first error calls next(err) two times and traverses my 2 error handlers. But when next(err2) is called on the 2nd error, we are already beind my 2 error handlers in the route stack, and the finalHandler is called. This happens often in a rest api style app (which is our case) : some route ask to do some operation on multiple business objects, we do all operations in, for instance, a "async.parallel", but due to a legitimate problems, some of those operations return an error. In such case, I would like to configure my app to do : log all the errors to the database send to the client a proper error 500 with a custom message corresponding to the first error that occured (there is a good chance the next errors will have the same cause and message, but even if not, this is still the desired behaviour) I read an argument saying that if we are sending a "normal" response to the client, and an error occur, it's preferable to stop everything, that to finish sending the response to the client and making it belive that everything is OK. I would argue that :