Feature #18438


Add `Exception#additional_message` to show additional error information

Added by mame (Yusuke Endoh) 6 months ago. Updated 5 months ago.

Target version:



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

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

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

PoC implementation:


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

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:

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 (Ivo Anjo)


  • 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
  • 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.


截圖 2021-12-27 15.56.00.png (74.9 KB) 截圖 2021-12-27 15.56.00.png st0012 (Stan Lo), 12/27/2021 03:58 PM

Related issues 1 (1 open0 closed)

Related to Ruby master - Feature #18296: Custom exception formatting should override `Exception#full_message`.OpenActions

Also available in: Atom PDF