You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've run into a complication with the way handler's ::default_status is used.
Presumably, the "proper" way for a custom handler to derive and expose status codes is to override #status_code. Within this method, I was expecting to be able to:
return @status code if set (which would presumably mean the :status option was explicitly passed to register_exception
derive the status code from the exception class if not set.
fallback to the handler's ::default_status if the exception class didn't define its own status code
Because the handler's default_status is "forced" into the options hash, it is impossible for a custom handler to differentiate between an explicit status provided to register_exception from the handler's own default status used in place of the :status option.
To work around this, I presently have some pretty hacky code:
classCustomHandler < RescueRegistry::ExceptionHandler# sentinel to distinguish explicit :status option from this defaultdefself.default_status9000end# Let the exception tell us which status code it maps todefstatus_code# respect explicit :status option if providedreturnsuperifstatus < self.class.default_status# otherwise, derive from exceptionexception.status.presence || 500end
I'm hoping that it would be possible to eliminate the status = options[:status] ||= handler.default_status and instead have ExceptionHandler's inherited implementation of status_code be @status.presence || self.class.default_status? That way subclasses which override status_code could distinguish an explicit :status (b/c @status would be non-nil); and still invoke super to get the default value if they wish?
I can open a PR to this effect unless there's some other known logic depending on the current behavior.
The text was updated successfully, but these errors were encountered:
First off, let me note that I'm a big fan of Chesterton so I approve of him being referenced :)
Unfortunately, it's been a while since I worked on this project so I'm not 100% sure that even I remember all of my rationale. It also looks like I didn't specifically test this, so that's less than ideal :/
One option might be to allow default_status to take an argument of the current exception, though I guess that might technically be a breaking change.
I've run into a complication with the way handler's
::default_status
is used.Presumably, the "proper" way for a custom handler to derive and expose status codes is to override
#status_code
. Within this method, I was expecting to be able to:register_exception
::default_status
if the exception class didn't define its own status codeHowever, this line is causing issues:
rescue_registry/lib/rescue_registry/registry.rb
Line 31 in eea958f
Because the handler's default_status is "forced" into the options hash, it is impossible for a custom handler to differentiate between an explicit status provided to
register_exception
from the handler's own default status used in place of the:status
option.I don't think I understand the rationale well enough to offer a PR with an alternative. (https://en.wikipedia.org/wiki/Wikipedia_talk:Chesterton%27s_fence) So discussing it here instead 😄
To work around this, I presently have some pretty hacky code:
I'm hoping that it would be possible to eliminate the
status = options[:status] ||= handler.default_status
and instead haveExceptionHandler
's inherited implementation ofstatus_code
be@status.presence || self.class.default_status
? That way subclasses which overridestatus_code
could distinguish an explicit :status (b/c @status would be non-nil); and still invokesuper
to get the default value if they wish?I can open a PR to this effect unless there's some other known logic depending on the current behavior.
The text was updated successfully, but these errors were encountered: