(Apologies if this is already covered anywhere. I did look and couldn't find anything, but I may very well have missed it!)
Expected Behavior
If anything goes catastrophically wrong within a handler, it would be good to return an HTTP 500 response to the client.
Even better would be the option to customize what the error response is.
Current Behavior
Currently, the server just hangs up the network connection.
It does not seem to break the threading - I can make many more panicking requests to the server than it is running threads and they all connect just fine. I just don't get a decent error.
Steps to Reproduce (for bugs)
- Write a handler
- Call - e.g.
unwrap() on an Err value from within the handler
Context
There are certain classes of errors that are catastrophic in nature. For example, the database not being present. Adding deliberate error propagation for these scenarios only serves to bloat the codebase - all of a sudden I've got to propagate the errors all the way from the bottom layer up to the handlers in order to return an error.
Alternatively, I can just not care about these. Just call pool.get().await.unwrap() to get a connection from the connection pool, for example. If I get a connection then that's great. If I don't then I have a catastrophic failure on my hands anyway, so panicking isn't unreasonable.
I could wrap every single handler in panic::catch_unwind() and handle it myself, but this is then a lot of duplication of effort, and has the need to return appropriate catastrophic errors from every handler. (I'm also not sure how to use catch_unwind in an async context, but that's my problem :) )
Alternatively, if Actix-web can do this then it only needs to be done once, and can have guaranteed consistent responses no matter which handler had the problem.
Obviously, this should only apply to actual catastrophic failures. Business errors, validation errors, etc are the domain of the application and not of Actix-web and should remain as such.
Your Environment
- Rust Version (I.e, output of
rustc -V): rustc 1.45.0-nightly (a08c47310 2020-05-07)
- Actix Web Version:
-> % cargo tree | grep actix
├── actix-cors v0.2.0
├── actix-http v1.0.1 (*)
├── actix-rt v1.1.1 (*)
├── actix-web v2.0.0 (*)
(Apologies if this is already covered anywhere. I did look and couldn't find anything, but I may very well have missed it!)
Expected Behavior
If anything goes catastrophically wrong within a handler, it would be good to return an HTTP 500 response to the client.
Even better would be the option to customize what the error response is.
Current Behavior
Currently, the server just hangs up the network connection.
It does not seem to break the threading - I can make many more panicking requests to the server than it is running threads and they all connect just fine. I just don't get a decent error.
Steps to Reproduce (for bugs)
unwrap()on an Err value from within the handlerContext
There are certain classes of errors that are catastrophic in nature. For example, the database not being present. Adding deliberate error propagation for these scenarios only serves to bloat the codebase - all of a sudden I've got to propagate the errors all the way from the bottom layer up to the handlers in order to return an error.
Alternatively, I can just not care about these. Just call
pool.get().await.unwrap()to get a connection from the connection pool, for example. If I get a connection then that's great. If I don't then I have a catastrophic failure on my hands anyway, so panicking isn't unreasonable.I could wrap every single handler in
panic::catch_unwind()and handle it myself, but this is then a lot of duplication of effort, and has the need to return appropriate catastrophic errors from every handler. (I'm also not sure how to usecatch_unwindin an async context, but that's my problem :) )Alternatively, if Actix-web can do this then it only needs to be done once, and can have guaranteed consistent responses no matter which handler had the problem.
Obviously, this should only apply to actual catastrophic failures. Business errors, validation errors, etc are the domain of the application and not of Actix-web and should remain as such.
Your Environment
rustc -V): rustc 1.45.0-nightly (a08c47310 2020-05-07)