When an error occurs in NodeJS application, the server may crash and stop if an exception occurs.
How can I prevent this situation so that the server never stops on error, but returns and error code instead ?
--
EDIT
Here is a method which causes a server crash (table foo doesn't exist) :
app.get('/articles/list', function(req, res) {
connection.query('select * from foo', function(err, rows, fields) {
if (err) throw err;
res.send(JSON.stringify(rows));
});
});
-- BEST SOLUTION
Finally, I found the best solution for me :
http://rowanmanning.com/posts/node-cluster-and-express/
In summary, it consists in using a cluster of server, and to restart a server when it exits
If you are using express, you can use this
function clientErrorHandler (err, req, res, next) {
if (req.xhr) {
res.status(500).send({ error: 'Something failed!' })
} else {
next(err)
}
}
app.use(clientErrorHandler);
I suggest you to ready this article, it will clarify a lot for you.
JFK, be aware of async error catching, most common error, once you have async stuff which is wrapped in try-catch.
Also, avoid usage of
process.on("uncaughException", () => {....})
This is quite bad, because when an uncaught exception is thrown you can’t reliably continue your program at this point.Let it fail and restart with daemonizer's like pm2, forever and etc.
As general rule, you should handle all errors and promise rejects in your code to avoid uncaught Exceptions.
For errors: using try-catch statement
For promises: using .catch method
Btw Node permits you to intercept an uncaughtExceptions or unhandledRejection events, but is not a good practice to handle errors at this level and prevent program exits, because can generate unpredictable behaviours.
Use try catch... for parts of code, which throws exception
try{
//youre code here
}catch(error){
console.log(error)
}
Related
I have a node.js service that is being called from a main application. I've had issues where an error occurs in the service and the service hangs preventing any other requests from being handled. I have code to catch errors in common places like after doing a mongodb query.
model.aggregate(
[
...
],function (err, result) {
if (err) {
next(err);
}
else {
//other code
}
I am also catching uncaught exceptions and killing the service in this case with the following code.
process.on('uncaughtException', function (er) {
console.error(er.stack);
logger.log('info','Cbt Dev Service crashed',er);
process.exit(1);
});
These seem to be working fine except I occasionally run into issues where an error occurs but isn't caught by either. An exmple of an error in this case is after getting a result from a mongodb query and getting an error like "Cannot read property 'subjectAreas' of undefined. This error seems to get caught by the mongodb middleware. The code looks like this.
function (err, result) {
if (err) {
res.send(errorHandler(err, req));
}
else {
var subjectAreas = result[0].subjectAreas.sort();
}
In this case result is an empty array so obviously throws an error. I understand that I can prevent this with better written code like using try/catch but if I'm not aware this issue exists and the service hangs up again, I don't know what the error is in order to fix it so that's why I need to log it.
Is there something else I can do that will catch these kinds of errors?
I spent too much time trying to figure out why my express.js controller did not respond to a simple query, and figured out that runtime errors fired from a Mongoose-promise callback were silently interrupting the callback process.
Here is a simplified version of my code:
server.get('/api/test', function (req, res, next) {
User.find({}).exec().then(function success(users){
console.log('SUCCESS');
typo[0] = 1; // throws a runtime error
res.json(users);
}, function error(err){
console.log('ERROR');
res.json({error: err});
});
});
This results in SUCCESS showing up in my console, but nothing happens then. No response is given to the user, the error caused by my typo is not appearing in my console, and the error callback is not called either.
I am aware that one should not throw exceptions from a callback function, but in that case, this was just a typo, and it would make sense to me to be warned (e.g. a stack trace in my standard output) whenever one makes this kind of mistake. (we're humans, after all...)
In your opinion, what's the best way to get feedback whenever this kind of mistakes are made in promise callbacks?
This is Mongoose's fault for using a bad promise implementation. Promises are throw-safe so exceptions are caught (so they can be later handled by future code) - the future code never comes and Mongoose never reports that it did not. Good promise implementations do not suffer from this issue.
Your options are two:
Use a library like Bluebird:
var Promise = require("bluebird");
var mongoose = Promise.promisifyAll(require("mongoose"));
User.findAsync({}).then(function(data){
JSON.prase("dsa"); // not a silent failure, will show up, easy debugging
});
This has the advantage of being faster than mongoose promises so there is no performance penalty. Alternatively, if you're super conservative and don't want the performance and API gains of bluebird - you can use native promises:
// Promise is the native promise
Promise.resolve(User.find({}).exec()).then(function(data){
JSON.prase("dsa");
});
And then, assuming you're running a modern variant of nodejs (read: io.js v 1.4.1 or upper), you can subscribe to promise rejections:
process.on("unhandledRejection", function(p, why){
console.log("FOUND ERROR!!!!", p , why);
});
So exceptions are not silently suppressed.
The exec() has two promises
.then(function)
.then(null , function)
try this, I think it will help
server.get('/api/test', function(req, res, next) {
User.find({}).exec()
.then(function success(users) {
console.log('SUCCESS');
typo[0] = 1; // throws a runtime error
res.json(users);
})
.then(null, function error(err) {
console.log('ERROR');
res.json({
error: err
});
});
});
I want to use Node.js Domains to catch exceptions. It is working so far, but there is one place I can't get domains to catch the exception. exception2 in the callback is caught and handled in the domain.on('error') handler, but exception1 is not caught. The odd thing is that when exception1 is thrown, it doesn't shutdown Node like I would expect. Here is my example app:
var domain = require('domain');
var request = require('request');
var express = require('express');
var serverDomain = domain.create();
serverDomain.on('error', function(err) {
console.log("Server Domain Error: " + err);
});
var app;
serverDomain.run(function() {
app = express();
app.listen(3000);
});
app.use(function(req, res, next) {
var reqDomain = domain.create();
reqDomain.add(req);
reqDomain.add(res);
reqDomain.on('error', function(err) {
console.log("Req Domain Error: " + err);
reqDomain.dispose();
next(err);
});
next();
});
app.get('/', function(req, res) {
var uri = "http://google.com";
exception1.go();
request.get({url:uri, json: {}},
function (error, response, body) {
if(response.statusCode === 200) {
exception2.go();
res.send('Success getting google response');
}
});
});
To get exception2 to execute, I comment out exception 1.
The problem is that the exception happens during Connect's routing, which has both a try/catch block around its execution, as well as a default error handler which prints out stack trace details when running in a non-production mode. Since the exception is handled inside of Express, it never reaches your outer layer for the domains to handle.
How it differs from exception2 is that the handler function for the '/' route is executed directly by that Connect block, in the same stack as the original call that went through Express. The second exception occurs in a callback, after some I/O operation has returned, and therefore is executed by a stack originating from Node's event loop I/O handler, and so the try/catch of Express isn't available to snag that exception and save the app server. In fact, if you comment out all the domain stuff, and trip exception2 it crashes Node.
Since only unhandled exceptions are routed to the domain mechanism, and since exception1 has a try/catch visible in it's call stack above it, the exception is handled, and not forwarded to the domain.
Connect-domain allows you to catch all errors for connect modules including express.
Connect-domain
https://github.com/baryshev/connect-domain
The example for express3:
http://masashi-k.blogspot.com/2012/12/express3-global-error-handling-domain.html
#user1007983
No, in production, the try/catch handling still exists in Connect/Express. The way to solve it is to add your own try/catch block in the "root" which you can then use to emit an "error" event to the domain before connect sends the error response.
try {
// .. code here ..
} catch (err) {
domain.emit('error', err);
}
Another way to get around it is to just disconnect from the handler, like wrapping your code in a setImmediate block
I've tried try/catch blocks (which may not work the way you think with async code). I've tried node domains in several different ways. But I was unable to handle an exception thrown in a 3rd party lib (sequelize). Why did I get the exception? Well, it was because the SQL that was generated was not well formed. (My fault).
Anywho, the solution that worked best for me and my (small) project was to use forever. Let the exceptions happen, but fire up node again if they do. I doubt it is the most elegant solution, but it works for me and my small project.
With a larger project, domains combined with the clustering API might be a good choice.
Winston is another choice. It might be cool to combine forever with winston so that if you DO get an exception, you can have winston email you, so you can fix the code. Meanwhile, forever will happily restart the app for you.
I came across this problem while testing my domain-based error handling.
I went with the approach suggested here by Issac, with a couple of minor changes: use 'domain.active' to get the currently active domain and emit the error event on that, and I used a wrapper function to avoid having to modify all of my handler functions:
domainWrapper = function(func) {
return function(req, res) {
try {
return func(req, res);
} catch (err) {
domain.active.emit('error', err);
}
}
}
Then changed this sort of thing:
app.get('/jobs', handlerFunc);
to this:
app.get('/jobs', domainWrapper(handlerFunc));
It seems like error reporting/handling is done differently in Node.js+Express.js applications compared to other frameworks. Am I correct in understanding that it works as follows?
A) Detect errors by receiving them as parameters to your callback functions. For example:
doSomethingAndRunCallback(function(err) {
if(err) { … }
});
B) Report errors in MIDDLEWARE by calling next(err). Example:
handleRequest(req, res, next) {
// An error occurs…
next(err);
}
C) Report errors in ROUTES by throwing the error. Example:
app.get('/home', function(req, res) {
// An error occurs
throw err;
});
D) Handle errors by configuring your own error handler via app.error() or use the generic Connect error handler. Example:
app.error(function(err, req, res, next) {
console.error(err);
res.send('Fail Whale, yo.');
});
Are these four principles the basis for all error handling/reporting in Node.js+Express.js applications?
Error handling in Node.js is generally of the format A). Most callbacks return an error object as the first argument or null.
Express.js uses middleware and the middleware syntax uses B) and E) (mentioned below).
C) is bad practice if you ask me.
app.get('/home', function(req, res) {
// An error occurs
throw err;
});
You can easily rewrite the above as
app.get('/home', function(req, res, next) {
// An error occurs
next(err);
});
Middleware syntax is valid in a get request.
As for D)
(07:26:37 PM) tjholowaychuk: app.error is removed in 3.x
TJ just confirmed that app.error is deprecated in favor of E
E)
app.use(function(err, req, res, next) {
// Only handle `next(err)` calls
});
Any middleware that has a length of 4 (4 arguments) is considered error middleware. When one calls next(err) connect goes and calls error-based middleware.
People at Joyent have published a really insightful best-practices document on this. A must-read article for any Node.js developer.
Why first-parameter?
Because of the asynchronous nature of Node.js, the first-parameter-as-err pattern has become well established as a convention for userland Node.js error handling. This is because asynchronous:
try {
setTimeout(function() {
throw 'something broke' //Some random error
}, 5)
}
catch(e) {
//Will never get caught
}
So instead having the first argument of the callback is pretty much the only sensible way to pass errors asynchronously other than just throwing them.
To do so will result in an unhandled exception which, just in the way it sounds, implies that nothing was done to get the application out of its confused state.
Exceptions, why do they exist
It is worth noting however, that virtually all part of Node.js are event-emitters and the throwing of an exception is a low-level event which can be handled like all events:
//This won't immediately crash if connection fails
var socket = require("net").createConnection(5000);
socket.on("error", function(err) {
console.error("calm down...", err)
});
This can-but-shouldn't be taken to the extreme to catch all errors and make an application which will try very hard to never crash. This is a terrible idea in nearly every use-case, because it will leave the developer without any idea of what's going on in the application state and is analogous to wrapping main in try-catch.
Domains - grouping events logically
As part of dealing with this problem of exceptions making applications fall over, domains allow the developer to take, for example the Express.js application, and try and close off connections sensibly in the event of catastrophic failure.
ES6
It's probably mentioning that this will change again as ES6 allows the generator pattern to create asynchronous events which are still catchable with try/catch blocks.
Koa (written by TJ Holowaychuck, same original author of Express.js) noticeably does this. It uses the ES6 yield statement to create blocks that, while appearing nearly syncronous, are handled in the usual node asynchronous fashion:
app.use(function *(next) {
try {
yield next;
}
catch (err) {
this.status = err.status || 500;
this.body = err.message;
this.app.emit('error', err, this);
}
});
app.use(function *(next) {
throw new Error('some error');
})
This example was shamelessly stolen from here.
I have a Node.js (v5.6.0, npm: v3.7.1) app running with Sails.js (v0.12.0).
When I execute this code in app.js:
process.on('uncaughtException', err => {
//Do something
});
throw new Error();
It handles my error.
The problem is, after I load Sails, I can't catch errors with this method at all.
For example, throwing an error from bootstrap.js will not be caught by the above code and I get this message in my console:
error: Bootstrap encountered an error: (see below)
error: Error: asdf
at Object.module.exports.bootstrap.process.on.process.on.process.on.sails.async.series.callback [as bootstrap]
(c:\path\to\project\config\bootstrap
.js:41:8)
at Sails.runBootstrap (c:\path\to\project\node_modules\sails\lib\app\private\bootstrap.js:44:25)
at Sails.wrapper [as runBootstrap] (c:\path\to\project\node_modules\sails\node_modules\lodash\index.js:3095:19)
at Sails.initialize (c:\path\to\project\node_modules\sails\lib\app\private\initialize.js:54:9)
at wrapper (c:\path\to\project\node_modules\sails\node_modules\lodash\index.js:3095:19)
at c:\path\to\project\node_modules\sails\node_modules\async\lib\async.js:713:13
at iterate (c:\path\to\project\node_modules\sails\node_modules\async\lib\async.js:262:13)
at c:\path\to\project\node_modules\sails\node_modules\async\lib\async.js:274:29
at c:\path\to\project\node_modules\sails\node_modules\async\lib\async.js:44:16
at c:\path\to\project\node_modules\sails\node_modules\async\lib\async.js:718:17
at c:\path\to\project\node_modules\sails\node_modules\async\lib\async.js:167:37
at module.exports (c:\path\to\project\node_modules\sails\lib\app\load.js:184:13)
at _toString (c:\path\to\project\node_modules\sails\node_modules\async\lib\async.js:52:16)
at c:\path\to\project\node_modules\sails\node_modules\async\lib\async.js:548:17
at c:\path\to\project\node_modules\sails\node_modules\async\lib\async.js:542:17
at _arrayEach (c:\path\to\project\node_modules\sails\node_modules\async\lib\async.js:85:13) [Error: asdf]
I also tried to move the above code in bootstrap.js without any luck.
How can I handle any error with Sails project?
Thanks in advance!
For whom will come here and looks for full code, I'm posting my full code and explanation, based on #sgress454 answer:
Sails is a Web Framework that wraps your code to a web application, so it can't be never down, therefore-Sails try to handle all the errors by itself, and notify the user with 500 if needed, and continue to run the web application.
Sails app is divided into 2 steps:
Before Lifting-The web application isn't accessible by anyone:
If Sails got exception, it will quit the app, and call the lift callback with an error argument.
After Lifting-The web application is accessible:
If Sails got exception, it will quit the app, and call the lift callback with an error argument.
If Sails got exception while running the web application(after lifting), there's 2 options:
Exception inside a controller action itself:
Sails will catch this error, and respond to the user with 500.
Exception wherever else:
Sails wouldn't catch this error, and an uncaughtException will be thrown.
To handle all the above case we need to do the following:
First we want to create a global function so we can call it from wherever we are in the code:
ES 2015:
//app.js
global.handleErrors = err => {
//do something
}
ES 5.1(and before):
//app.js
global.handleErrors = function(err) {
//do something
}
Now we want to handle all uncaughtException's events:
//app.js
process.on('uncaughtException', handleErrors);
We can add some other events ex.:
//app.js
process.on('unhandledRejection', handleErrors);
process.on('rejectionHandled', handleErrors);
process.on('SIGINT', handleErrors);
To catch exceptions that happens in the lifting process we need to provide a callback to sails.lift function, and if the callback is called with an error we need to call the handleErrors function that we created:
ES 2015:
//app.js
sails.lift(rc('sails'), err => {
if (err) {
handleErrors(err);
}
});
ES 5.1(and before):
//app.js
sails.lift(rc('sails'), function(err) {
if (err) {
handleErrors(err);
}
});
And we want to handle exceptions in controllers that Sails catches and responded with 500:
//api/responses/serverError.js
module.exports = function serverError(data, options) {
handleErrors(data);
//lot of Sails things
};
In this way all the errors eventually will be hit the handleErrors function, so we can do there whatever we want with the error, ex. log to file, log to log management tool, send email to admin etc.
The code you posted will do exactly what it says: handle uncaught exceptions. Sails handles errors that occur during its initialization so it can attempt to exit gracefully, and attempts to handler errors that occur when processing requests so it can respond gracefully (with an error page) instead of crashing the server.
To handle errors that occur during the initialization process, provide a second argument--an error handling function--to .lift() in your app.js file:
sails.lift(rc('sails'), function handleLiftError(err, sailsInstance) {
if (err) {
console.log("Error occurred during sails.lift: ", err);
}
});
You can still leave your process.on('uncaughtException'),... code in to handle fatal errors that pop up as the app is running. For instance, if you had the following in a controller action:
myAction: function (req, res) {
throw new Error('foo!);
}
then Sails would catch that error for you and just respond with the 500 error page. But if you had:
myAction: function (req, res) {
setTimeout(function(){throw new Error('foo!);}
}
Sails would not catch it at all--but your process.on handler would (provided you started Sails with node app.js!)