2

I've read Joyent's stellar guide on error handling in node. I'm also familiar with using error middleware in Express to handle errors. However, there's one detail that continues to perplex me: how do you decide when to percolate up the error to the caller (e.g. with cb(err) or throw new Error()) vs. pass along to the error handler middleware (with next(err))?

I'll use the fetchConfig example function in the Joyent article to illustrate my question. The pathway of the function is as follows:

  1. Load configuration
    1. Connect to the database server. This in turn will:
      1. Resolve the DNS hostname of the database server
      2. Make a TCP connection to the database server.
      3. Authenticate to the database server
    2. Make the DB request
    3. Decode the response
    4. Load the configuration
  2. Start handling requests

Let's assume there's an express error handler (the function(err, res, req, next) {} pattern) that exists to log the error message and pass it along to the client.

(Still borrowing from the Joyent article...) Let's say the connection in 1.1.2 fails: myserver: Error: connect ECONNREFUSED. In step 1.1.2, if you handled the error in that module by calling next(err), you'd be logging a rather cryptic error message.

Instead, you first want the error to percolate through steps 1.1 and 1, wrapping the error message as you go to produce a clearer error message: myserver: failed to start up: failed to load configuration: failed to connect to database server: failed to connect to 127.0.0.1 port 1234: connect ECONNREFUSED

To me, this indicates that the programmer must make a decision at every stage of the error to either a) wrap and pass the error to its caller, or b) pass the error to the express error handler. My question is centered on that decision: what guides the decision, how does one choose logically and consistently?

Thanks to any that may help.

Andrew Smith
  • 1,434
  • 13
  • 29
  • You might want to rework you question. I honestly am not certain what exactly you are asking, and from the title I thought this would be an easy question. You might want to look at [this question](http://stackoverflow.com/questions/7151487/error-handling-principles-for-nodejs-express-apps?rq=1) and its answer and see if that helps resolve your questions. – barry-johnson Mar 19 '15 at 23:00
  • @barry-johnson: thanks for the feedback, I've refactored the question. Thanks for the link as well, I had read through that one previously. It's very useful, but I don't think it addresses my question. Let me know if it's clear what I'm now asking. – Andrew Smith Mar 21 '15 at 20:21
  • I believe it is more clear what you are asking, but other possible responders may appreciate you correcting the formatting of the function to indicate the additional nesting of flow as illustrated in the Joyent article. As it regards your question specifically, I would say it may be too abstract to get useful guidance. The Joyent article is quite good. My advice would be to write a couple of programs and start dealing with errors. It will help make more sense of the Joyent advice and will give you more concrete questions to ask. – barry-johnson Mar 21 '15 at 22:25

1 Answers1

-1

This is error handling code generated by express when init project using express command.

// error handlers
// development error handler
// will print stacktrace
if (app.get('env') === 'development') {
  app.use(function(err, req, res, next) {
    res.status(err.status || 500);
    res.render('error', {
      message: 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('error', {
    message: err.message,
    error: {}
  });
});
Kartal
  • 424
  • 5
  • 13
vishal patel
  • 832
  • 1
  • 7
  • 21