Rewrite handle_exception to apply backtrace filtering to Exception#backtrace instead of Exception#full_message

[joshbroughton]

Description

Backtraces in the Rails console are being almost completely silenced (see the issue in Rails. The expected behaviour with the Rails backtrace_cleaner is that only non-application lines in the backtrace will be silenced, so that only lines form the user's application code will be shown in a backtrace.

The cause of the issue is that IRB's handle_exception method uses Exception#full_message to generate the backtrace lines before calling filter_backtrace. Exception#full_message adds string formatting ('\tfrom') to the backtrace lines; the Rails cleaner is expecting a backtrace format that conforms to Exception#backtrace, and needs to be able to continue to clean backtraces from sources outside the console that do conform that API. We could work around this from the Rails side, but feel that that would be adding complexity/patching over a problem instead of addressing the root cause.

More generally, upstream projects that use IRB can reasonably expect that filter_backtrace acts on Exception#backtrace, rather than split lines of Exception#full_message. handle_exception should be re-written to conform to this expectation.

This also surfaced some changes that should be made filter_backtrace - I will create a separate issue to describe those.

Thanks for the feedback on how to approach this @st0012 - excerpt below

I agree that passing backtrace with from to the filter_backtrace API isn’t the best practice for upstream projects that use it.
And instead of using full_message, I think we can use Exception#detailed_message and Exception#backtrace