-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Forward errors along to error handling middlewares #11
Forward errors along to error handling middlewares #11
Conversation
cd18df2
to
052ef84
Compare
Looks like this is an alternative to #4. |
Note to self, write test to check what happens if we have no error handling middleware. |
052ef84
to
b975bb3
Compare
@tomdale Updated test cases to include testing error propagation when there is no custom error handling middleware. Can you double check the cases for accuracy? I'm happy to add any more that you can think of as well. |
|
res.status(result.statusCode); | ||
res.send(html); | ||
}) | ||
.catch(error => { | ||
console.log(error.stack); | ||
log(500, error.stack); | ||
next(error); | ||
res.sendStatus(500); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we res.status
here instead, so that middleware can alter the response, instead of being forced to deal with sendStatus
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup. will do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
next
should be called last
91e3c13
to
5cbeaf5
Compare
@danmcclain @tomdale Look it over one more time? |
res.sendStatus(500); | ||
} | ||
if (error.name !== "UnrecognizedURLError") { | ||
res.status(500); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we even need to do this? Or would the default handler do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should set 500
because that accurately reflects the state of the request when it leaves the FastBoot middleware.
If post-FastBoot middleware wants to change the status code and attempt recovery it can. But that doesn't change the fact that our middleware resulted in an internal server error (i.e., a 500
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arjansingh That rationale sounds reasonable to me.
5cbeaf5
to
28e3ee2
Compare
@danmcclain @tomdale Bueller? 😁 |
Thanks @arjansingh 👏 |
This would address issues discussed in: ember-fastboot/fastboot#76
Relevant express documentation: https://expressjs.com/en/guide/error-handling.html