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
If upstream projects (like Rails) want to extend or alter the behaviour of filter_backtrace, they currently have to override the filter_backtrace method (like Rails does here). Directly overriding a method of the internal WorkSpace component is not a great way to extend a behaviour. Instead, we could add a config that creates a more proper way for upstream projects to extend the filter.
A better way to do this would be to:
Introduce IRB.conf[:backtrace_filter] that’s invoked after filter_backtrace is called.
Ideally, IRB.conf[:backtrace_filter] = Rails.backtrace_cleaner should fully replace the current handle_exception patch. But we’ll see if that’s possible when we have a PR
The above means that IRB’d expect the value of backtrace_filter to implement a filter(array_of_backtrace) method
Thanks for the suggestion on how to approach this @st0012
The text was updated successfully, but these errors were encountered:
Description
If upstream projects (like Rails) want to extend or alter the behaviour of
filter_backtrace
, they currently have to override thefilter_backtrace
method (like Rails does here). Directly overriding a method of the internalWorkSpace
component is not a great way to extend a behaviour. Instead, we could add a config that creates a more proper way for upstream projects to extend the filter.A better way to do this would be to:
Thanks for the suggestion on how to approach this @st0012
The text was updated successfully, but these errors were encountered: