From: "mame (Yusuke Endoh)" Date: 2021-12-06T04:59:47+00:00 Subject: [ruby-core:106502] [Ruby master Feature#18370] Call Exception#full_message to print exceptions reaching the top-level Issue #18370 has been updated by mame (Yusuke Endoh). Please clearly write the motivation first. Cite from https://bugs.ruby-lang.org/issues/18296#note-14 * Callers can choose whether they want `did_you_mean/error_highlight` (individually) in the exception message or not, and they have a way to get the original exception message (just `Exception#message` would be the original message). * It makes it possible to choose more dynamically than global --disable-`did_you_mean/error_highlight`. Given e.g. error_highlight has a non-trivial performance impact, it seems useful to be able only get this output in some situations where the caller might know whether it is useful. * `did_you_mean/error_highlight` can find out about options given to `full_message` such as `highlight:`, or even introduce their own additional options (keyword arguments). For instance `error_highlight` could use `highlight:` to decide whether to use ANSI sequences to colorize the failing call, or to use `^^^^` on the next line (I know @ioquatix cares about this flexibility). This can be useful e.g. to have different output for Exception#inspect (don't want ANSI escape sequences, and probably not extra information) and printing the exception to a terminal (all information and ANSI escape sequences). Some test harness might choose different trade-offs, and this lets them choose. * It's a cleaner integration than overriding `#message`, it can allow more gems to customize exceptions and there is no problem if some exception subclasses override `#message`. To be honest, I don't feel the need so much. --- Even if the interpreter uses `#full_message` for an uncaught exception, I will extend `#message` in error_highlight for a while. The reason is because of some application monitoring services like Sentry, DataDog, ScoutAPM, etc. I believe that they are not using `#full_message` because they are providing their own backtrace filtering. It is not trivial to use `#full_message` for their use case. I may change my opinion if the developers of Sentry, DataDog, and/or ScoutSPM join this discussion. --- I guess that we need the following changes in addition to eregon's proposal. * Introduce `Exception#additional_message(highlight: true, **)` * `full_message(**opt)` should output `#message`, `#additional_message(*opt)`, and backtrace in turn. * did_you_mean and error_highlight overwrites `#additional_message` instead of `#message` In this case, APM services can use `#additional_message` to construct a message string. In other words, this requires APM services to support `#additional_message`. I'm not positive against this change unless the APM developers join this dicussion. Rails developer may want to join the discussion because they also have their own error message renderer. ---------------------------------------- Feature #18370: Call Exception#full_message to print exceptions reaching the top-level https://bugs.ruby-lang.org/issues/18370#change-95162 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- Extracted from https://bugs.ruby-lang.org/issues/18296#note-6. I think this a clear gain to improve consistency in how exceptions are shown, and it also makes it easier to evolve exception formatting in the future. It would also solve https://bugs.ruby-lang.org/issues/18367. https://bugs.ruby-lang.org/issues/18296#note-7 has more specifics, I'll copy here for convenience: mame (Yusuke Endoh) wrote in #note-6: > Does this proposal include that the ruby interpreter should use `#full_message` to show the error information? This is an incompatibility, is it acceptable? Yes, let's fix that. I don't think there is much if any compatibility issue here. The output of the uncaught exception handler is already the same as the default Exception#full_message AFAIK, let's actually call it. TruffleRuby already calls `exc.full_message` for the uncaught exception handler. If the custom `exc.full_message` raises an exception, then it's best to report that exception *and* the original exception using the default `Exception#full_message` (written in C). This is the current TruffleRuby output for that case and I think it's clear: ``` $ ruby -e 'class Foo < Exception; def full_message(**); raise "bar"; end; end; raise Foo, "message"' Error while formatting Ruby exception: -e:1:in `full_message': bar (RuntimeError) from core/truffle/exception_operations.rb:183:in `get_formatted_backtrace' Original Ruby exception: -e:1:in `
': message (Foo) ``` -- https://bugs.ruby-lang.org/ Unsubscribe: