Programmatic handling of 404 and 500 error codes.

[Philipp Winter]

Hey folks,

I wanted to ask you how to properly handle 404 and 500 errors.

Until this moment, I used the following snippet at the end of my loading to realize this:

app.use(function(req, res) {
       res.status(404);
       data.wrapAndRender('error.dust', {code: 404});
});
app.use(function(error, req, res) {
       console.error(error.stack);
   res.status(500);
   data.wrapAndRender('error.dust', {code: 500});

});

As I wanted to add routes dynamically (after calling those use statements) they automatically catched every request. Is there a possibility to keep both, well styled error messages and dynamic route adding?

With kind regards

Philipp Winter

[Paul Vencill]

What I usually do is have all my middleware and routes call next(err) when something goes wrong, with err being a custom error object that includes enough info for my error handling middleware to figure out the right status code and message, then the error handling middleware handles logging and responds with that info to the client (sanitized of course).

--
You received this message because you are subscribed to the Google Groups "Express" group.
To unsubscribe from this group and stop receiving emails from it, send an email to express-js+...@googlegroups.com.
To post to this group, send email to expre...@googlegroups.com.
Visit this group at http://groups.google.com/group/express-js.
For more options, visit https://groups.google.com/d/optout.

[Philipp Winter]

Thanks for your answer, although to me this seems to be very verbose, as I only want to provide a general-purpose "404:Not found" or "500: Server Error" message, which is identically created each time.

As I'm only going to need the dynamic loading during the startup phase of my application (for now), the way to go is probably to emit an event saying that each dynamic route has been added now and it's safe to include the error pages for now.

Although this seems not practical in a scenario where constant changes to the route handling are necessary, it should fix my problem.

If anyone knows a more general purpose solution, feel free to add it. 

[Paul Vencill]

It's not that verbose.  It actually streamlines your control flow a lot, letting each function do one thing well.

For example, given a defined NotFoundError, I can just say

if(!user)
   return next(new NotFoundError());

in the callback from the database or ORM query, immediately exiting that handler and going to my error handling middleware.  The NotFoundError class would already define the default status and message, and the middleware can use that to configure a generic response.

--

[Ryan Schmidt]

On Mar 9, 2015, at 11:41 AM, Paul Vencill wrote:

> It's not that verbose. It actually streamlines your control flow a lot, letting each function do one thing well.
>
> For example, given a defined NotFoundError, I can just say
>
> if(!user)
> return next(new NotFoundError());
>
> in the callback from the database or ORM query, immediately exiting that handler and going to my error handling middleware. The NotFoundError class would already define the default status and message, and the middleware can use that to configure a generic response.

I've seen this advice before, but the big caveat for me is the "given a defined NotFoundError". Where do you define it? If you're trying not to have your entire application in a single file, then you have to define or include NotFoundError and any other errors you use in each file, which seems to be tedious.

var NotFoundError = require('./NotFoundError.js');
var InvalidEntryError = require('./InvalidEntryError.js');

and so on. How do you handle it?

[Jason Crawford]

You could do that, or you could put them all in a single 'errors' module:

var errors = require('./errors.js');

... return next(new errors.NotFoundError());

-Jason