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
During an error, the ActionDispatch::DebugExceptions error page tries displays the first Application Trace backtrace. Now, this is rarely the first backtrace and we (in Web Console) always presume the binding we have to choose by default is for the first one.
This often put is in a situation where an error is raised inside of framework code that is invoked from an application code. The error the user sees looks like it's raised from the application code (as this is the piece of code the error page shows), while the binding we have for the console is deep inside the framework code and it looks like Web Console "doesn't work". I think we should fix that for the next release and try to make a good guess which should be the first binding we choose.
While at it, I think we should drill on providing a mapping between exception bindings and exception backtraces, as we often can't match with the binding for the backtrace we click from the UI. Say, we have an exception that originated in C code – we cannot build a Ruby Binding object for that frame, however, we can probably provide a dummy binding object, in which evaluating code can explain why we can't evaluate code in there.
The text was updated successfully, but these errors were encountered:
During an error, the
ActionDispatch::DebugExceptions
error page tries displays the firstApplication Trace
backtrace. Now, this is rarely the first backtrace and we (in Web Console) always presume the binding we have to choose by default is for the first one.This often put is in a situation where an error is raised inside of framework code that is invoked from an application code. The error the user sees looks like it's raised from the application code (as this is the piece of code the error page shows), while the binding we have for the console is deep inside the framework code and it looks like Web Console "doesn't work". I think we should fix that for the next release and try to make a good guess which should be the first binding we choose.
While at it, I think we should drill on providing a mapping between exception bindings and exception backtraces, as we often can't match with the binding for the backtrace we click from the UI. Say, we have an exception that originated in C code – we cannot build a Ruby Binding object for that frame, however, we can probably provide a dummy binding object, in which evaluating code can explain why we can't evaluate code in there.
The text was updated successfully, but these errors were encountered: