[ruby-core:106907] [Ruby master Feature#18438] Add `Exception#additional_message` to show additional error information

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


So this serves roughly the same purpose as #18296

I also have a slight preference for a `description` method that includes the `message`. It seem simpler for everyone (including Sentry, Datadog, etc.) to use `e.description` instead of `e.message + "\n" + e.additional_message`, and also easier to support older rubies. But I'm curious if the `additional_message` approach has some advantage I overlooked.

There's also the question of who/what is responsible for the ansi/terminal formatting? It seems in this design, `additional_message` is a simple string and all formatting (bold) is handled by `full_message`. Nice and simple. With `description` we can (should?) delegate all formatting to this method, so it's very flexible and powerful.


byroot (Jean Boussier) wrote in #note-4:
> `Exception#description` which would be:

I had the same thought initially but there's a hiccup: the description needed by full_message should include the (underlined) error type, but the description needed by Sentry should not. That makes the design somewhat less elegant. You would need something like

```ruby
class Exception
  def description(highlight: false, append_type: false, **)
    msg = message
    if append_type
      type = self.class.name
      type = ANSI_UNDERLINE_ON + type + ANSI_UNDERLINE_OFF if highlight
      msg = msg.sub(/$/, " (" + type + ")")
    end
    msg = ANSI_BOLD_ON + msg + ANSI_BOLD_OFF if highlight
    msg
  end

  def full_message(**opts)
    description(highlight: true, append_type: true, **opts) + "\n" + backtrace_str
  end
end
```


----------------------------------------
Feature #18438: Add `Exception#additional_message` to show additional error information
https://bugs.ruby-lang.org/issues/18438#change-95725

* Author: mame (Yusuke Endoh)
* Status: Open
* Priority: Normal
----------------------------------------
## Proposal

I'd like to introduce a method `Exception#additional_message`, and let the Ruby error printer show it after `Exception#message`.

```ruby
class MyError < StandardError
  def message = "my error!"
  def additional_message = "This is\nan additional\nmessage"
end

raise MyError
```

```
$ ./miniruby test.rb
test.rb:6:in `<main>': my error! (MyError)
| This is
| an additional
| message
```

PoC implementation: https://github.com/ruby/ruby/pull/5351

## Motivation

At the present time, did_you_mean and error_highlight overrides `Exception#message` to add their suggestions.

```ruby
begin; 1.time; rescue NoMethodError; pp $!.message; end
#=> "undefined method `time' for 1:Integer\n" +
#   "\n" +
#   "  1.time\n" +
#   "   ^^^^^\n" +
#   "Did you mean?  times"
```

This implementation approach has a practical problem. Because it changes the return value of `Exception#message`, it breaks a test that checks the return value of `Exception#message`.
Though such a test is never recommended, I encountered some actual cases when creating error_highlight. See the change of tests of minitest as a typical example: https://github.com/seattlerb/minitest/pull/880/files

Currently, error_highlight shows hint information only for NoMethodError because it is relatively rare to check the message of `NameError`. Still, it broke some tests unfortunately, though. If possible, I'd like to add suggestions to other kinds of errors, but it will break much more tests.

If `Exception#additional_message` is introduced, and if did_you_mean and error_highlight overrides the method to add their suggestions, this problem will not occur because they no longer changes the result value of `#message` method.

## Cooperation needed

Currently, many Ruby/Rails users montiors their production services by using application monitoring services such as Sentry, DataDog, ScoutAPM, etc. The original motivation of error_highlight is for production (see #17930), so it will lose the significance if such services do not support `Exception#additional_message`. So, I'd like to hear opinions from developers of such services. If they are against this proposal or if we can't get their cooperation, I don't think my proposal should be accepted.

If you are a developer of these services, I would be very grateful if you could comment on this ticket. @ivoanjo

## Bikesheds

* I'm unsure if `Exception#additional_message` is a good name. Please propose alternatives if it is not good.
* Currently, the result of `addtional_message` is printed with no escape. This may be a more compatible solution against https://bugs.ruby-lang.org/issues/18367.
* It may be good to let `Exception#additional_message` accept `highlight` keyword as boolean information whether the output target is a terminal or not. Currently `Exception#full_message` accepts it. I have no plan to use the information in `error_highlight`, though. Not only `highlight` but also any keywords may be forwarded from `full_message(**opt)` to `additional_message(**opt)` for future use case.
* My current PoC adds prefixs "`| `" before each line of `addtional_message`. I'm unsure if this is good or bad. I'm happy to change or remove the prefixes.

---Files--------------------------------
截圖 2021-12-27 15.56.00.png (74.9 KB)


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

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