From: "mame (Yusuke Endoh)" <noreply@ruby-lang.org>
To: ruby-core@neon.ruby-lang.org
Subject: [ruby-core:110740] [Ruby master Feature#18564] Add Exception#detailed_message
Date: Mon, 14 Nov 2022 03:11:31 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-100076.20221114031130.18@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-18564.20220201194925.18@ruby-lang.org
Issue #18564 has been updated by mame (Yusuke Endoh).
Status changed from Open to Closed
I think I have already merged the change. Closing.
----------------------------------------
Feature #18564: Add Exception#detailed_message
https://bugs.ruby-lang.org/issues/18564#change-100076
* Author: mame (Yusuke Endoh)
* Status: Closed
* Priority: Normal
* Assignee: mame (Yusuke Endoh)
----------------------------------------
(This ticket is for recording the final spec of #18438)
## Proposal
I would introduce a method `Exception#detailed_message`, and let the default error printer use it instead of `Exception#message` to create a error output.
```
class MyClass < StandardError
def message = "my error!"
def detailed_message(highlight: false, **opt)
super + "\nThis is\nan additional\nmessage"
end
end
raise MyClass
```
```
$ ./miniruby test.rb
test.rb:8:in `<main>': my error! (MyClass)
This is
an additional
message
```
Here is the implementation: https://github.com/ruby/ruby/pull/5516
## Spec
`Exception#detailed_message(highlight: false)` calls `#message` and decorates the returned string. It may add the class name of exception and, when `highlight` keyword is true, some escape sequences for highlights.
```
e = RuntimeError.new("my error!")
p e.detailed_message #=> "my error! (RuntimeError)"
p e.detailed_message(highlight: true) #=> "\e[1mmy error! (\e[1;4mRuntimeError\e[m\e[1m)\e[m"
```
Previously, the default error printer and `Exception#full_message` called `#message` to get the error message, applied some processing (adding the error class name and adding escape sequences) to the string, and added backtrace. Now, they now use `#detailed_message(highlight: Exception.to_tty?)` instead of `#message`.
All keyword arguments passed to `Exception#full_message` are delegated to `detailed_message`.
## Motivation
The primary motivation is a clean integration of did_you_mean and error_highlight gems.
At the present time, they overrides `Exception#to_s` to add their suggestions. However, there are some known problems in this approach:
* It may break some tests to check the result of `Exception#to_s` depending on whether the gems add suggestions or not.
* Some Ruby scripts re-raise an exception by `raise e.class, e.message, e.backtrace`, which makes the gems add their suggestion multiple times (currently, [the gems ad-hocly check and avoid multiple addition](https://github.com/ruby/did_you_mean/blob/531760f323df8d43a7017af5a3052f20e8a03fda/lib/did_you_mean/core_ext/name_error.rb#L18)).
* Sometimes a user needs to get the original message without their addition. For the sake, did_you_mean provides `Exception#original_message`, but [the workaround is not very well known](https://github.com/ruby/error_highlight/pull/10).
This proposal allows the gems to override `Exception#detailed_message`. `Exception#to_s` is kept as-is, so the above problems will no longer occur.
Also, the proposal allows a user to get a full_message without the suggestions by `err.full_message(did_you_mean: false, error_highlight: false)`.
Here is a proof-of-concept patch for did_you_mean and error_highlight: https://gist.github.com/mame/2c34230f11237dc4af64510cb98acdd8 I'll create PRs for the gems after `Exception#detailed_message` is merged.
# Cooperation needed
This change requires application monitoring services such as Sentry, DataDog, ScoutAPM, etc. They need to use `Exception#detailed_message(highlight: false)` instead of `Exception#message` to log the error messages after Ruby 3.2. Thankfully, @st0012 (the maintainer of Sentry's Ruby SDK) and @ivoanjo and @marcotc (the maintainers of Datadog's application monitoring gem) have agreed with this change.
https://bugs.ruby-lang.org/issues/18438#note-1
https://bugs.ruby-lang.org/issues/18438#note-9
@matz has already approved this proposal in #18438 . I'll merge my PR in a few days after some reviews.
--
https://bugs.ruby-lang.org/
prev parent reply other threads:[~2022-11-14 3:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-01 19:49 [ruby-core:107417] [Ruby master Feature#18564] Add Exception#detailed_message mame (Yusuke Endoh)
2022-11-14 3:11 ` mame (Yusuke Endoh) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-100076.20221114031130.18@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
--cc=ruby-core@neon.ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).