Introduce ActionDispatch::DebugExceptions interceptors #23868
Conversation
|
r? @matthewd (@rails-bot has picked a reviewer for you, use r? to override) |
gsamokovarov
force-pushed the
gsamokovarov:debug-exceptions-interceptors
branch
2 times, most recently
| backtrace_cleaner = request.get_header('action_dispatch.backtrace_cleaner') | ||
| wrapper = ExceptionWrapper.new(backtrace_cleaner, exception) | ||
|
|
||
| @interceptors.each do |interceptor| |
maclover7
Feb 24, 2016
Member
Can we get rid of the transitory @interceptors, and just call self.class.interceptors here?
Can we get rid of the transitory @interceptors, and just call self.class.interceptors here?
gsamokovarov
Feb 24, 2016
Author
Contributor
Injected it, so I can test it more easily – no need to keep track of the global state during the test run.
Injected it, so I can test it more easily – no need to keep track of the global state during the test run.
maclover7
Feb 24, 2016
Member
🤷 I just think it would make sense to use the direct variable we will iterating on, instead of creating a shadow variable, that we won't even be changing.
| raise exception unless request.show_exceptions? | ||
| render_exception(request, exception) | ||
| end | ||
|
|
||
| private | ||
|
|
||
| def invoke_interceptors(request, exception) |
maclover7
Feb 24, 2016
Member
We could call this method from inside render_exception, or should set the backtrace_cleaner and wrapper variables to be instance variables, so we don't have to create the same thing multiple times 😬
We could call this method from inside render_exception, or should set the backtrace_cleaner and wrapper variables to be instance variables, so we don't have to create the same thing multiple times
gsamokovarov
Feb 24, 2016
Author
Contributor
I tried something similar, let me see what I can do.
I tried something similar, let me see what I can do.
|
As the maintainer of an exception notifier ( |
| raise exception unless request.show_exceptions? | ||
| render_exception(request, exception) | ||
| render_exception(request, exception, wrapper) |
gsamokovarov
Feb 27, 2016
Author
Contributor
Actually, this breaks the render_exception interface, and plugin authors already depend on it. I'm going with the duplicated code approach. Yeah, I like DRY code, but sometimes the duplication is so much better than breaking interfaces or leaking abstractions.
Actually, this breaks the render_exception interface, and plugin authors already depend on it. I'm going with the duplicated code approach. Yeah, I like DRY code, but sometimes the duplication is so much better than breaking interfaces or leaking abstractions.
gsamokovarov
force-pushed the
gsamokovarov:debug-exceptions-interceptors
branch
2 times, most recently
|
@gsamokovarov Is @rafaelfranca @matthewd Is there anything I can do to help move this forward? |
|
@tgxworld Yes, it is still monkey patching... You can make I still stand by the interceptors, though. They are super simple and provide what most of the plugins monkey patching |
|
The idea looks good to me. @gsamokovarov can you rebase it? |
gsamokovarov
force-pushed the
gsamokovarov:debug-exceptions-interceptors
branch
3 times, most recently
Plugins interacting with the exceptions caught and displayed by ActionDispatch::DebugExceptions currently have to monkey patch it to get the much needed exception for their calculation. With DebugExceptions.register_interceptor, plugin authors can hook into DebugExceptions and process the exception, before being rendered. They can store it into the request and process it on the way back of the middleware chain execution or act on it straight in the interceptor. The interceptors can be play blocks, procs, lambdas or any object that responds to `#call`.
gsamokovarov
force-pushed the
gsamokovarov:debug-exceptions-interceptors
branch
to
d25fba8
|
@rafaelfranca I have rebased it. |
|
|
Plugins interacting with the exceptions caught and displayed by
ActionDispatch::DebugExceptionscurrently have to monkey patch it to getthe much needed exception for their calculation.
With
DebugExceptions.register_interceptor, plugin authors can hook intoDebugExceptionsand process the exception, before being rendered. Theycan store it into the request and process it on the way back of the
middleware chain execution or act on it straight in the interceptor.
The interceptors can be plain blocks, procs, lambdas or any object that
responds to
#call.You can see
web-consoleimplemented through the interceptor API here.Other plugin authors can benefit from this API as well. Most of the error
reporting plugins can use this.