-
-
Couldn't load subscription status.
- Fork 1.2k
Description
The purpose of a rescue_from block is of course to handle exceptions in a custom way. However, what should happen if the rescue_from block itself raises an exception? Currently, Grape does not handle such exceptions, likely resulting in an Internal Server Error returned by the web server.
In some cases, it would be beneficial if an exception raised inside a rescue_from block was handled by another rescue_from block. However, it’s unclear whether that’s a good idea in general, as it could result in an infinite rescue_from block loop.
I have a use case where Grape::Exceptions::ValidationErrors should be remapped to a different exception that is a subclass of Grape::Exceptions::Base. What I currently do is the following:
rescue_from Grape::Exceptions::ValidationErrors do |e|
begin
raise Api::Exceptions::InvalidValueError, e.full_messages
rescue Api::Exceptions::InvalidValueError => invalid_value_error
run_rescue_handler(:error_response, invalid_value_error)
end
endHowever, it no longer works with newer Grape versions (probably since #2377).
For this use case, it would be best if it was possible to raise an exception in the rescue_from block that is then handled by the default rescue handler for Grape exceptions. If that’s an option, I can try to come up with sensible semantics that allow that while avoiding infinite loops.
Otherwise, I’d welcome suggestions for handling this use case cleanly and such that it works with current Grape versions. The best I’ve come up with is to call #error!, however it can be a bit fiddly to convert the exception to the correct arguments for #error!. Note that this requires a recent fix (#2471).