I want to test Exception on a node process. Instead of registering handler like in error.js file.
error.js
process.on("uncaughtException", (ex) => {
//logging
process.exit(-1);
});
Sorry, I do not have comment privileges yet, but you can write a function that will throw an uncaughtException call before your test. Please let me know if this works.
Related
i have a custom handler for uncaught exceptions that i want to test. with all the attempts, i have also tried inside a forked child process as well.
this is a contrived example...
process.on('uncaughtException', function(err) {
otherFunction(err.message);
});
it('should catch exceptions', function() {
stub(otherFunction);
throw new Error('foo');
assert.calledWith(otherFunction, 'foo');
});
is there something i need to use with my stubbing tool (currently using sinon), or is this entirely the wrong approach?
Any error thrown inside an itfunction should fail that test. You can wrap the throw statement with try{} and in catch block you can write the assert function.
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)
}
I have a npm module which has main() function as its starting point.
Now, lets say I throw an Error immediently in that main() as shown below:
function main() {
throw new Error("An error!");
}
And then execute it with node my-app-that-launchers-main.js then obviously, the error is thrown and I get a stacktrace.
If I write a grunt task for this:
var mynpm = require("mynpm");
module.exports = function(grunt) {
grunt.registerTask("build",function() {
mynpm.build();
});
}
And execute it via Grunt, then it fails. The error is thrown and grunt fails, as expected.
However, if I wrap this throw inside a Bluebird Promise:
function main() {
Promise.try(function(resolve) {
throw new Error("An error!");
} ).catch(function() {
console.log("error");
} ).finally(function() {
console.log("finally");
});
}
And run it via node then I see that the catch function is invoked. As expected.
However, if I run the same code via Grunt's registertask, everything becomes dead silent. Nor the catch or the finally is called.
What could be causing this. It seems like Grunt hijacks errors are thrown.
Its a super easy to reproduce this, yet I am so puzzled about why.
Does Grunt hijack errors that are thrown, somehow, so not even the Promise's catch and finally functions gets invoked?
How can the execution and the error handling be so different if its executed manually, compared with if Grunt executes the code?
You are looking to define an async task. This can be done using this.async():
grunt.registerTask("build",function() {
// Tell Grunt this task is asynchronous.
var done = this.async();
mynpm.build();
});
More information about async tasks here : https://gruntjs.com/api/inside-tasks
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));
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!)