From: "mame (Yusuke Endoh)" <noreply@...> Date: 2022-02-03T01:28:33+00:00 Subject: [ruby-core:107453] [Ruby master Feature#18438] Add `Exception#additional_message` to show additional error information Issue #18438 has been updated by mame (Yusuke Endoh). Dan0042 (Daniel DeLorme) wrote in #note-22: > My concern was that Sentry will now use #detailed_message instead of #message, but it will now include the exception class, unlike before. But if Sentry is ok with that there's no problem. Ah, that's a good point. @matz what do you think? ---------------------------------------- Feature #18438: Add `Exception#additional_message` to show additional error information https://bugs.ruby-lang.org/issues/18438#change-96357 * 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:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>