Moved IsReject from sealed to expose its function #891
Conversation
… use in custom error handling so the status codes and such from warp builtin rejections can then still be used.
You can currently check a rejection using |
Yes, but as far as I'm aware, this means having to check for each different Rejection error individually if you want to find out the correct status code (or other info). There is no blanket way to just pick a few errors you want to handle in a custom way, while leaving the rest to be handled as default. In the rejections.rs example on the repo, custom error handling leads to every error that is not specifically handled (of which there are more than a dozen) to instead default to a 500 Internal Server Error, which isn't very pretty. |
They shouldn't default to a 500. After specifically handling the ones you care about, you can return the rejections and most will be turned into a corresponding 4xx response. Usually only the "something really bad happened" and "custom" rejections will render as a 500. |
My apologies, I do see there is a way to fully emulate the default error behavior for those. I do hope a way to still expose some info about rejections will be possible, because I would like to wrap some additional text around the default rejection string. But since I cannot access those, I believe that's still not possible. |
|
@seanmonstar Hi, it seems a lot of other people have run into similar problems related to the fact that you cannot expose any internal information from a Rejection. Already in 2018 some people where experiencing issues with custom handling of Rejections (#134). More recently there was #451, where you also contributed to the discussion and even suggested some solutions, but then never got back to them. Two PRs were made that could solve it (#820 is probably the most idiomatically Rust, #827 is a simple expose similar to my "hackish" solution), but #820 is still waiting for your review. Your post in #388 shares some insight that Rejection is not really meant for this type of pattern, but even if that's the case, it would be nice to be able to unify the handling of business logic errors and request errors using the infrastructure that already exists (Filter recover). I understand you are busy and maybe don't have the time to write something that can solve the problems the people mentioned are having, but I'm sure there are others here who like this library and might be interested in writing something. That aside, allowing this PR or #820 would at least provide a temporary solution. The only thing I really need is the status code from the Rejection. Currently, like you said in your above comments, it is possible to leave the rejection untouched for errors you care less about and let the default do its thing, but this makes it impossible to wrap it with any kind of additional information or text. Having the status code allows at least some information that can be used to wrap the Rejection. I hope you can find some time to look at #820 (probably better than this PR and which can also immediately close #827) or this one. Thanks! |
Why this change?
Warp supports almost all HTTP error codes. As such, when making a bad request to a warp server, warp will throw the appropriate error and return the correct status code. However, when using custom error handling (with a recover filter) it is not possible to use these builtin rejections. This simple change exposes IsReject, which exposes the status code and other things for use in custom error handling.