[ruby-core:106699] [Ruby master Feature#18296] Custom exception formatting should override `Exception#full_message`.

Issue #18296 has been updated by Dan0042 (Daniel DeLorme).


I'm interested in this feature because I'm uncomfortable with the current situation of sticking everything into `Exception#message` and losing access to the original message.

In #18194 I think everyone has agreed that
> an error message might be formatted for both the terminal and a log file, which have different formatting requirements.

(and also html formatting via `Rack::ShowExceptions` where all whitespace in the message is collapsed.)
Overall I think this `full_message` idea is really the best way to achieve these different formatting requirements. And in particular this:
> we'd need a new method that's basically the same as full_message but always without the backtrace

is basically the same thing as `Exception#detailed_information` that @mame suggested in #18194#note-4

So if I try to summarize all this, there's a need for three different kinds of "message": (names are only for illustration)
1. `original_message` =>  The original string provided to Exception.new; there really should be _some_ way to get the unmodified message
2. `detailed_message(**opts)` => The original_message plus additional info (did_you_mean and error_highlight), optionally with terminal highlighting; `opts` allows to override the global on/off defaults for highlighting and did_you_mean and error_highlight. Alternatively it could be `detailed_information(**opts)`, just the info without the original_message.
3. `full_message(**opts)` => Same as above, but with backtrace as well. Using this for the top-level formatter would improve maintainability.

There's a bit of an issue concerning what `Exception#message` should be.
a) Ideally it would be the unmodified `original_message`. So detailed_ or full_message must be used to get error_highlight information.
b) @mame really wants error_highlight's information in Sentry's error reports, which only uses `message` at the moment. So it can be either a no-`opts` version of `detailed_message`, or else `detailed_message` could actually be called just `message`.

It seems to me that since error_highlight is only for NameError, and NameError doesn't happen so often in production, and Sentry is for gathering error reports in production... the value of putting error_highlight info in `Exception#message` for the sake of Sentry is fairly limited. IMHO, not enough to be worth changing the semantics of `Exception#message` so much. I feel that option a) above is a better, cleaner choice in the long run.

Respectfully.


----------------------------------------
Feature #18296: Custom exception formatting should override `Exception#full_message`.
https://bugs.ruby-lang.org/issues/18296#change-95381

* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
----------------------------------------
After discussing with @eregon, we came to the conclusion that the current implementation of `did_you_mean` and `error_highlight` could avoid many issues by using `Exception#full_message`.

We propose to introduce a more nuanced interface:

```ruby
class Exception
  def full_message(highlight: bool, order: [:top or :bottom], **options)
    # ...
  end
end

module DidYouMean
  module Formatter
    def full_message(highlight:, did_you_mean: true, **options)
      buffer = super(highlight: highlight, **options).dup
      buffer << "extra stuff"
    end
  end
end
Exception.prepend DidYouMean::Formatter

module ErrorHighlight
  module Formatter
    def full_message(highlight:, error_highlight: true, **options)
      # same as above
    end
  end
end
Exception.prepend ErrorHighlight::Formatter
```



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>