Core: How do I handle 404s?

Created on 23 Mar 2016  路  12Comments  路  Source: adonisjs/core

Hi, I'm pretty new to Adonis and I am having some issues regarding 404 errors in production. Unfortunately, when you visit a non existent route Adonis exhibits weird (?) behavior and crashes immediately.

I am wondering how I can handle this error.

Thanks.

Most helpful comment

That doctrine is less valid today given ES6 control flows and it depends on the type of the exception, i.e. Sensibly uncaught exceptions (which are becoming more rare giving excellent try/catch capabilities brought about by ES6 generators), and not as the regulated response for ALL exceptions.
404's and most common HTTP errors, should never qualify as rebootable exceptions on the framework level. Especially not a framework that prides itself on being ES6 and convention-over-config.
UncaughtExceptions, by their very nature of being uncaught, kill the app on their own, in which case yes the best thing to do is to restart it. And remember, the article you linked also says the best solution is to NOT allow obvious exceptions to remain uncaught.

Theory context mismatch aside, the realities of running a server dictates that you have to account for attacks. Rebooting an app takes extremely precious time.
If it becomes clear that certain urls on your app makes your entire server-side app reboot, what self-respecting black-hat won't have a field day messing up your entire cluster with a loop/swarm attack? :D That would be the easiest site to bring down and KEEP down.

This aside, I still like AdonisJS. I appreciate the cleanness of it. As time goes on I might have a few pull requests thrown in :)

Thanks for the great work Harminder

All 12 comments

Inside bootstrap/start.js there is a block to listen to error event and same is used to handle error. https://github.com/adonisjs/adonis-app/blob/develop/bootstrap/start.js#L51.

If you have better suggestions, i am all open to improve http error handling

I think if we could have some sort of error handling within the routes file that would be great. Something along the lines of how ExpressJS does it with Middleware perhaps?

I have added the Event provider to the core of the framework, it will make it possible to handle Http errors , in a better way.

Teaser

const Event = use('Event')
Event.when('Http.404', 'Http.handle404')

Here Http.handle404 comes from app/Listeners/Http.js file.

Http.handle404 = function * (error, request, response) {
  yield response.sendView('errors/404')
}

This will become part of new release

Hi Harminder, thanks for the great work.
Also For now, line 55 of bootstrap/start.js should be removed in any serious app.

//process.exit(1)
In the current state of this project, 404s cause the entire server to crash. Calling that an over-sight is a massive over-simplification. That means all it takes is for GoogleBot to crawl an adonisJS site the wrong way and it will crash. That's too brittle.

Being a singular thread, The node process should never be voluntarily ended.
Nothing should kill it of it's own volition.
That design pattern of ending process upon a simple sneeze only makes sense if you are writing PHP, not server-side ES6 Javascript.

Nope, you should always let your application crash and get re-started by deamons like forever or pm2. http://shapeshed.com/uncaught-exceptions-in-node/

For http 404 error, you can manually add a check on status to see if it's 404 or not. For any other errors you should make the process die, failing fast and first is always a good practice

That doctrine is less valid today given ES6 control flows and it depends on the type of the exception, i.e. Sensibly uncaught exceptions (which are becoming more rare giving excellent try/catch capabilities brought about by ES6 generators), and not as the regulated response for ALL exceptions.
404's and most common HTTP errors, should never qualify as rebootable exceptions on the framework level. Especially not a framework that prides itself on being ES6 and convention-over-config.
UncaughtExceptions, by their very nature of being uncaught, kill the app on their own, in which case yes the best thing to do is to restart it. And remember, the article you linked also says the best solution is to NOT allow obvious exceptions to remain uncaught.

Theory context mismatch aside, the realities of running a server dictates that you have to account for attacks. Rebooting an app takes extremely precious time.
If it becomes clear that certain urls on your app makes your entire server-side app reboot, what self-respecting black-hat won't have a field day messing up your entire cluster with a loop/swarm attack? :D That would be the easiest site to bring down and KEEP down.

This aside, I still like AdonisJS. I appreciate the cleanness of it. As time goes on I might have a few pull requests thrown in :)

Thanks for the great work Harminder

Awesome stuff here, I forward to 3.0/

Hello Everyone!!!
The fact that Adonisjs handle various errors is great, but it is always a good practice to make an app prepared for all errors and not let a framework to show an error itself, that errors are actually for developers, and it fill be embarrassing to have a live web application which is accidentally can show an system error.
So, even that from bootstrap/events.js this Event.when('Http.error.*', 'Http.handleError') navigates to /app/Listeners/Http.js it is not a event solution, but it is awesome cause by 2 lines of simple code we can handle an important case of 404's simply adding

if (status === 404 )
    yield response.sendView('front')

Hey @DBadalyan! 馃憢

The error you are currently seeing is only for development purpose, on production, these will not be displayed.

@RomainLanz Oh, I'm new to Adonis, playing with it from yesterday, now I see it acts wonderful. Happy to learn that. Actually, I really appreciate the great job of Adonis developers.

By the way the method which I mentioned can be used as a thing to render different views, in related errors.
can you give a confirmation?

Yes!

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dezashibi picture dezashibi  路  4Comments

umaams picture umaams  路  3Comments

itsg2jakhmola picture itsg2jakhmola  路  3Comments

aligoren picture aligoren  路  4Comments

imperez picture imperez  路  4Comments