From: "Dan0042 (Daniel DeLorme)" Date: 2021-12-29T17:15:28+00:00 Subject: [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 `
': 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: