Unable to catch HTTP exceptions.
See original GitHub issue[Details] (Vague example) Right now, Oak is not throwing any error for non-existent routes. Even though the response code is set to 404, it is not interpreted as an error, thus it never gets to the error handling middleware.
[Error handling middleware] (Vague + pseudocode)
try {
await next()
} catch(error) {
response.body = `This is an error ${error.toString()}`
}
In theory, if an error was thrown because of the 404 route, it would return a response as shown above, but as an error is never thrown this never happens.
On the other hand, when I do this middleware:
await next();
console.log(context.response.status);
I can clearly see how it logs a 404 in the console.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (1 by maintainers)
Top Results From Across the Web
I can't catch a HTTP Client exception - Laracasts
I can't catch a HTTP Client exception. Hi all,. I am using the new(-ish) HTTP Client, something like this $response = Http::get($listToCheck->url);.
Read more >Why is it not possible to catch HTTP error in Angular when ...
When I shutdown the REST server there are errors in the console.log() but I'm unable to catch them in the service:
Read more >Handling Exceptions Using the Angular HttpClient Service
Catching HTTP Exceptions Using the catchError operator gives you the ability to catch errors that may occur within an observable stream. Let's ......
Read more >Drupal 8 -Unable to catch Http exceptions
I have been unable to catch exceptions despite having all requests go through a try-catch structure. I have tried use \GuzzleHttp\Exception\ ...
Read more >Introduction to Mule 4: Error Handlers | MuleSoft Documentation
Description: HTTP GET on resource 'http://localhost:36682/testPath' failed: unauthorized (401) Type: HTTP:UNAUTHORIZED Cause: a ResponseValidatorTypedException ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
It could maybe implemented as a opt in. I don’t think it would be too hard to implement support for
new Application({throwOnNotFound: true})
or something like thatHaving thought about this (yeah, I know, long time) and how the koa-router handles this, I think the current behaviour is what is expected, and that users should have a middleware that handles non-matched routes, as that is ultimately what stacked middleware should do, so having a 404 middleware that sets the right behaviours for the application at the end should be a common pattern. There are several examples of this in both koa and express.