https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112021-12-27T16:07:50ZRuby Issue Tracking SystemRuby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=956502021-12-27T16:07:50Zst0012 (Stan Lo)stan001212@gmail.com
<ul><li><strong>File</strong> <a href="/attachments/9152">截圖 2021-12-27 15.56.00.png</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/9152/%E6%88%AA%E5%9C%96%202021-12-27%2015.56.00.png">截圖 2021-12-27 15.56.00.png</a> added</li></ul><p>Hello, I'm Stan, the maintainer of <a href="https://github.com/getsentry/sentry-ruby" class="external">Sentry's Ruby SDK</a>.<br>
I think Sentry currently displays the overridden exception message as intended (see the image below). So to us, this separation is not needed atm.<br>
But if you want to extract the message as <code>additional_message</code> to keep things clean, that'll work for us too. Since Sentry doesn't accept any complementary attribute for exceptions, I'll just concat it with <code>message</code> and it should look the same.</p>
<p>Thanks for implementing such a great feature :-)</p>
<p><img src="https://redmine.ruby-lang.org/attachments/download/9152/%E6%88%AA%E5%9C%96%202021-12-27%2015.56.00.png" alt="" loading="lazy"></p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=956692021-12-28T04:08:06Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/11268">@st0012 (Stan Lo)</a> Thank you very much for your reply!</p>
<blockquote>
<p>So to us, this separation is not needed atm.</p>
</blockquote>
<p>The motivation of this separation is not for your services. Some Ruby programmers write a test to check the exception message like this.</p>
<pre><code>exc = (raise SomeError rescue $!)
assert_equal("exception message", exc.message)
</code></pre>
<p>This test will break if error_highlight extends <code>SomeError</code> class because currently error_highlight changes the return value of <code>SomeError#message</code>. If error_highlight overrides <code>#additional_message</code>, this kind of failures will not occur.</p>
<blockquote>
<p>But if you want to extract the message as additional_message to keep things clean, that'll work for us too. Since Sentry doesn't accept any complementary attribute for exceptions, I'll just concat it with message and it should look the same.</p>
</blockquote>
<p>Yes, I think that's a good enough way to handle the change!</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=956752021-12-28T11:00:04Zivoanjo (Ivo Anjo)ivo.anjo@datadoghq.com
<ul></ul><p>Thanks for the ping!</p>
<p>I'll need to sync with my colleagues at Datadog and may take a few days because a lot of people are off, but I have a few questions:</p>
<ol>
<li>Would <code>additional_message</code> only be something that gems like did_you_mean and error_highlight use (e.g. better debugging/developer experience tools), or do you see normal user code using it as well?</li>
<li>The prefixed <code>|</code> seem harmless, but could you clarify what their use-case is? Is it to make it clear, when printing, which part is the regular message and which part is the additional one?</li>
</ol> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=957182021-12-29T11:59:15Zbyroot (Jean Boussier)byroot@ruby-lang.org
<ul></ul><p>What if instead of having two distinct <code>#message</code> and <code>#additional_message</code> that need to be concatenated, there would simply be an alternative, more descriptive method?</p>
<p>e.g.</p>
<p><code>Exception#description</code> which would be:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="k">def</span> <span class="nf">message</span>
<span class="vi">@message</span>
<span class="k">end</span>
<span class="k">def</span> <span class="nf">description</span><span class="p">(</span><span class="ss">highlight: </span><span class="kp">false</span><span class="p">)</span>
<span class="s2">"</span><span class="si">#{</span><span class="n">message</span><span class="si">}</span><span class="se">\n</span><span class="s2">Some extra info"</span>
<span class="k">end</span>
<span class="k">def</span> <span class="nf">full_message</span><span class="p">(</span><span class="ss">highlight: </span><span class="kp">false</span><span class="p">,</span> <span class="ss">order: </span><span class="o">...</span><span class="p">)</span>
<span class="s2">"</span><span class="si">#{</span><span class="n">description</span><span class="p">(</span><span class="ss">highlight: </span><span class="n">highlight</span><span class="p">)</span><span class="si">}</span><span class="se">\n</span><span class="si">#{</span><span class="n">backtrace</span><span class="o">...</span><span class="si">}</span><span class="s2">"</span>
<span class="k">end</span>
</code></pre>
<p>The advantage being that it allows <code>description</code> to modify <code>message</code>.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=957212021-12-29T14:05:00Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>ivoanjo (Ivo Anjo) wrote in <a href="#note-3">#note-3</a>:</p>
<blockquote>
<ol>
<li>Would <code>additional_message</code> only be something that gems like did_you_mean and error_highlight use (e.g. better debugging/developer experience tools), or do you see normal user code using it as well?</li>
</ol>
</blockquote>
<p>My current motivation is only did_you_mean and error_highlight. But it is difficult to force everyone else not to use it, so I guess some users will use it for any reason that I don't see currently.</p>
<blockquote>
<ol start="2">
<li>The prefixed <code>|</code> seem harmless, but could you clarify what their use-case is? Is it to make it clear, when printing, which part is the regular message and which part is the additional one?</li>
</ol>
</blockquote>
<p>I have no strong use case. I'm okay to remove the prefix. I thought that they were useful to distinguish between a regular message and additional one, but it is possible to "fake" it by crafting a <code>#message</code>, such as <code>"the first line\n| faked additional message"</code>.</p>
<p>byroot (Jean Boussier) wrote in <a href="#note-4">#note-4</a>:</p>
<blockquote>
<p>What if instead of having two distinct <code>#message</code> and <code>#additional_message</code> that need to be concatenated, there would simply be an alternative, more descriptive method?<br>
<em>snip</em><br>
The advantage being that it allows <code>description</code> to modify <code>message</code>.</p>
</blockquote>
<p>I wonder if it is a good idea or not. Allowing to modify <code>message</code> might be useful in some cases, but I'm afraid if it would bring rather confusion.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=957252021-12-29T17:15:28ZDan0042 (Daniel DeLorme)
<ul></ul><p>So this serves roughly the same purpose as <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Custom exception formatting should override `Exception#full_message`. (Closed)" href="https://redmine.ruby-lang.org/issues/18296">#18296</a></p>
<p>I also have a slight preference for a <code>description</code> method that includes the <code>message</code>. It seem simpler for everyone (including Sentry, Datadog, etc.) to use <code>e.description</code> instead of <code>e.message + "\n" + e.additional_message</code>, and also easier to support older rubies. But I'm curious if the <code>additional_message</code> approach has some advantage I overlooked.</p>
<p>There's also the question of who/what is responsible for the ansi/terminal formatting? It seems in this design, <code>additional_message</code> is a simple string and all formatting (bold) is handled by <code>full_message</code>. Nice and simple. With <code>description</code> we can (should?) delegate all formatting to this method, so it's very flexible and powerful.</p>
<p>byroot (Jean Boussier) wrote in <a href="#note-4">#note-4</a>:</p>
<blockquote>
<p><code>Exception#description</code> which would be:</p>
</blockquote>
<p>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</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="k">class</span> <span class="nc">Exception</span>
<span class="k">def</span> <span class="nf">description</span><span class="p">(</span><span class="ss">highlight: </span><span class="kp">false</span><span class="p">,</span> <span class="ss">append_type: </span><span class="kp">false</span><span class="p">,</span> <span class="o">**</span><span class="p">)</span>
<span class="n">msg</span> <span class="o">=</span> <span class="n">message</span>
<span class="k">if</span> <span class="n">append_type</span>
<span class="n">type</span> <span class="o">=</span> <span class="nb">self</span><span class="p">.</span><span class="nf">class</span><span class="p">.</span><span class="nf">name</span>
<span class="n">type</span> <span class="o">=</span> <span class="no">ANSI_UNDERLINE_ON</span> <span class="o">+</span> <span class="n">type</span> <span class="o">+</span> <span class="no">ANSI_UNDERLINE_OFF</span> <span class="k">if</span> <span class="n">highlight</span>
<span class="n">msg</span> <span class="o">=</span> <span class="n">msg</span><span class="p">.</span><span class="nf">sub</span><span class="p">(</span><span class="sr">/$/</span><span class="p">,</span> <span class="s2">" ("</span> <span class="o">+</span> <span class="n">type</span> <span class="o">+</span> <span class="s2">")"</span><span class="p">)</span>
<span class="k">end</span>
<span class="n">msg</span> <span class="o">=</span> <span class="no">ANSI_BOLD_ON</span> <span class="o">+</span> <span class="n">msg</span> <span class="o">+</span> <span class="no">ANSI_BOLD_OFF</span> <span class="k">if</span> <span class="n">highlight</span>
<span class="n">msg</span>
<span class="k">end</span>
<span class="k">def</span> <span class="nf">full_message</span><span class="p">(</span><span class="o">**</span><span class="n">opts</span><span class="p">)</span>
<span class="n">description</span><span class="p">(</span><span class="ss">highlight: </span><span class="kp">true</span><span class="p">,</span> <span class="ss">append_type: </span><span class="kp">true</span><span class="p">,</span> <span class="o">**</span><span class="n">opts</span><span class="p">)</span> <span class="o">+</span> <span class="s2">"</span><span class="se">\n</span><span class="s2">"</span> <span class="o">+</span> <span class="n">backtrace_str</span>
<span class="k">end</span>
<span class="k">end</span>
</code></pre> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=957652022-01-01T11:36:56ZEregon (Benoit Daloze)
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/18296">Feature #18296</a>: Custom exception formatting should override `Exception#full_message`.</i> added</li></ul> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=957662022-01-01T11:49:07ZEregon (Benoit Daloze)
<ul></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/18">@mame (Yusuke Endoh)</a> Thanks for making this proposal, I believe it goes in the right direction.</p>
<p>Dan0042 (Daniel DeLorme) wrote in <a href="#note-6">#note-6</a>:</p>
<blockquote>
<p>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</p>
</blockquote>
<p>That part, showing the exception class name, should be handled by <code>#full_message</code>, like it currently is.<br>
<code>description</code> would only return "a more complete message" but not try to do any formatting which is already handled by <code>#full_message</code> (like the exception class, backtrace, causes, etc).<br>
In fact, <code>full_message</code> is far more complicated than what is shown in @byroot's example (which is fine since it's illustrative).<br>
See <a href="https://github.com/oracle/truffleruby/blob/39d740bd3eb8abafe737656055850fc7b3a4d1dc/src/main/ruby/truffleruby/core/exception.rb#L90-L130" class="external">https://github.com/oracle/truffleruby/blob/39d740bd3eb8abafe737656055850fc7b3a4d1dc/src/main/ruby/truffleruby/core/exception.rb#L90-L130</a> and <a href="https://github.com/oracle/truffleruby/blob/39d740bd3eb8abafe737656055850fc7b3a4d1dc/src/main/ruby/truffleruby/core/truffle/exception_operations.rb#L94-L112" class="external">https://github.com/oracle/truffleruby/blob/39d740bd3eb8abafe737656055850fc7b3a4d1dc/src/main/ruby/truffleruby/core/truffle/exception_operations.rb#L94-L112</a> for example.</p>
<p>I think the <code>description</code> approach is nice because it's easier to call (no manual concat) and also more flexible (access to original message, access to kwargs). +1 from me.<br>
Monitoring services can then just call <code>description(highlight: false)</code> instead of <code>message</code>.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=958192022-01-06T19:31:47Zmarcotc (Marco Costa)
<ul></ul><p>👋, I maintain <a href="https://github.com/DataDog/dd-trace-rb" class="external">Datadog's application monitoring gem</a>, alongside Ivo.</p>
<p>ivoanjo (Ivo Anjo) wrote in <a href="#note-3">#note-3</a>:</p>
<blockquote>
<p>I'll need to sync with my colleagues at Datadog and may take a few days because a lot of people are off</p>
</blockquote>
<p>Following up here, I agree with the <code>description</code> proposal:</p>
<p>Eregon (Benoit Daloze) wrote in <a href="#note-8">#note-8</a>:</p>
<blockquote>
<p>I think the <code>description</code> approach is nice because it's easier to call (no manual concat) and also more flexible (access to original message, access to kwargs). +1 from me.<br>
Monitoring services can then just call <code>description(highlight: false)</code> instead of <code>message</code>.</p>
</blockquote>
<p>For us, calling <code>description(highlight: false)</code> to have the richest possible textual information, then separately calling <code>backtrace</code> to get the code location would be the ideal APIs for error reporting.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=958682022-01-11T05:59:26Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p><code>Exception#description</code> seems to add too much flexibility and make responsibilities vague.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=958832022-01-11T14:38:49ZEregon (Benoit Daloze)
<ul></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/4">@nobu (Nobuyoshi Nakada)</a> How so? Do you have an example?</p>
<p>The responsibilities for <code>description</code> are to call <code>super</code> and include it in the return value. That's it, nothing else.</p>
<p>The same goes for <code>additional_message</code> and is necessary if there are multiple definitions of <code>additional_message</code> in the ancestors.<br>
Except it's less clear for <code>additional_message</code> because the default <code>additional_message</code> returns <code>""</code>.<br>
And so how to avoid an extra <code>\n</code> before? That'd probably means harder to write a correct <code>additional_message</code> => <code>msg = super; msg.empty? ? extra : "#{msg}\n#{extra}"</code>.<br>
This is not a problem for <code>description</code>, where <code>super</code> always returns a non-empty String (unless the original message is empty, but that's then basically a bug of who raised it) => <code>"#{super}\n#{extra}</code>.</p>
<p>The class, backtraces and causes are added later by <code>full_message</code>, because there is no value to add them before and it's not trivial to add them (the class is always shown on the first line, even for a multi-line message, that's already current behavior).</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=958852022-01-11T16:20:10ZDan0042 (Daniel DeLorme)
<ul></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/4">@nobu (Nobuyoshi Nakada)</a> did you mean that the name "description" is vague or the concept itself? Would you find it less vague if it was named something else? (e.g. "detailed_message" or something)</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=959492022-01-13T17:35:14Zst0012 (Stan Lo)stan001212@gmail.com
<ul></ul><blockquote>
<p>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.</p>
</blockquote>
<p>Not saying I like that but I think it's generally ok because</p>
<ol>
<li>Not many developers need to do this. Perhaps just SDK authors and some gem authors.</li>
<li>We still need to make the change anyway and maintain compatibility between versions.</li>
</ol>
<blockquote>
<p>Exception#description seems to add too much flexibility and make responsibilities vague.</p>
</blockquote>
<p>I also think <code>description</code> could be confusing. I'd say it's mainly because of the name instead of the concept. If I understand it correctly, it looks like <code>full_message</code> will be built on top of <code>description</code>, which will be <code>message</code> + additional information (like from <code>error_lighlight</code>)?</p>
<p>To me, it's hard to tell the difference between <code>description</code>, <code>message</code> and <code>full_message</code> from their names and certainly doesn't help understand the relationship between them.</p>
<p>I think <code>complemented_message</code> will be a clearer (but also verbose) name?</p>
<p>Then we'll have:</p>
<ul>
<li>
<code>message</code> - the most fundamental message of the exception.</li>
<li>
<code>complemented_message</code> - message with additional information to help debugging</li>
<li>
<code>full_message</code> - all of the above + type info + backtrace...etc.</li>
</ul> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=959562022-01-14T02:51:31Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>We discussed this topic yesterday at the dev-meeting. <a class="user active user-mention" href="https://redmine.ruby-lang.org/users/13">@matz (Yukihiro Matsumoto)</a> basically liked the API style of <code>Exception#description</code>, but disliked the name. <code>full_message</code> calls <code>description</code>, and <code>description</code> calls <code>message</code>, which looked awkward to matz. Anyone have a good suggestion about alternative names? Maybe <code>*_message</code> which comes between <code>full_message</code> and just `message would be preferable.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=960012022-01-16T21:25:28ZEregon (Benoit Daloze)
<ul></ul><p><code>detailed_message</code> maybe? (also the term used in <a href="https://bugs.ruby-lang.org/issues/18296#note-20" class="external">https://bugs.ruby-lang.org/issues/18296#note-20</a>)</p>
<p>IMHO <code>description</code> is fine and a good term in relation to <code>message</code>.<br>
<code>full_message</code> is a weird name to me because it includes the backtrace and it's not really a "message" anymore, but that's how it is and seems unlikely worth to be renamed now that it is established.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=962392022-01-29T08:10:39Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/13">@matz (Yukihiro Matsumoto)</a> accepted the name <code>detailed_message</code>. I'll update and improve my PR (or volunteer is welcome)</p>
<p>Note: the rdoc of <code>detailed_message</code> should explicitly state that the method should accept <code>highlight</code> keyword that allows using ANSI terminal escape sequences to highlight the error message. Also, the method should accept and ignore any unknown keywords because some gems (say, error_highlight) can accept a custom keyword to enable their own formatting customization (say, <code>error.full_message(error_highlight: false)</code>.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=962722022-01-30T23:10:59ZDan0042 (Daniel DeLorme)
<ul></ul><p>Very happy about this.</p>
<p>mame (Yusuke Endoh) wrote in <a href="#note-16">#note-16</a>:</p>
<blockquote>
<p>Note: the rdoc of <code>detailed_message</code> should explicitly state that the method should accept <code>highlight</code> keyword that allows using ANSI terminal escape sequences to highlight the error message.</p>
</blockquote>
<p>I'd like to ask for clarification regarding this. In #full_message, the #detailed_message is wrapped with bold, correct? In that case the <code>highlight</code> keyword for #detailed_message is for any highlighting except bold? That would also mean #detailed_message must not use "\e[0m" otherwise that would break the highlighting of #full_message? I think it would be good to clarify how the responsability of terminal highlighting is shared between #full_message and #detailed_message.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=962922022-01-31T10:31:19Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>I talked with <a class="user active user-mention" href="https://redmine.ruby-lang.org/users/13">@matz (Yukihiro Matsumoto)</a> and <a class="user active user-mention" href="https://redmine.ruby-lang.org/users/4">@nobu (Nobuyoshi Nakada)</a> about that.</p>
<p>The current implementation of <code>Exception#full_message</code> adds <code>\e[1m</code> (i.e., bold start) for each beginning of line of <code>#message</code>, and <code>e[m</code> (i.e., bold end) for each end. (Also, it adds <code>" (RuntimeError)"</code> or something to the last of the first line.)<br>
With that in mind, <code>#detailed_message</code> can freely add their own escape sequences. <code>Exception#full_message</code> won't check the result of <code>detailed_message</code>.</p>
<p>BTW, the behavior of <code>Exception#full_message</code> (adding <code>\e[1m</code> and <code>e[m</code>) will be moved to <code>Exception#detailed_message</code>. That is, a rough spec will be like the following.</p>
<pre><code>class Exception
def detailed_message
lines = message.lines.map { "\e[1m" + _1.chomp + "\e[m" }
lines[0] << " (#{ self.class.inspect })"
lines.join("\n")
end
def full_message
# frame is a string like "file.rb:lineno:in `method_name'"
head_frame, *tail_frames = backtrace
"#{ head_frame }: #{ detailed_message }\n" + tail_frames.map { "\tfrom " + _1 }.join("\n")
end
end
class MyError < StandardError
def detailed_message
# In general, user-defined detailed_message should prepend the result of "super"
"#{ super }\naddtional message"
end
end
</code></pre>
<p>Note that the "addtional message" part of <code>MyError#detailed_message</code> will not be automatically highlighted.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=962952022-01-31T15:58:15ZDan0042 (Daniel DeLorme)
<ul></ul><p>Thank you, it's much clearer now.</p>
<p>Follow-up question: Should #detailed_message include the class of the error<br>
a) always (unlike #message currently)<br>
b) only if <code>highlight</code> keyword is true<br>
c) based on some other keyword (like in <a href="#note-6">#note-6</a>)<br>
?</p>
<p>nitpick: "\e[0m" or "\e[m" is for full reset; imho it would be better to use "\e[22m" for bold-off (and "\e[24m" for underline-off). It allows things like adding color: <code>"\e[31m" + err.detailed_message(highlight:true) + "\e[39m"</code>.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=963152022-02-01T19:50:03Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>I have created another ticket to summarize the final spec of this proposal: <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Add Exception#detailed_message (Closed)" href="https://redmine.ruby-lang.org/issues/18564">#18564</a>.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=963272022-02-02T06:23:01Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/11019">@Dan0042 (Daniel DeLorme)</a> I think your last comment is a different topic. I'd like to keep one proposal as small as I can.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=963412022-02-02T14:51:26ZDan0042 (Daniel DeLorme)
<ul></ul><p>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.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=963572022-02-03T01:28:33Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>Dan0042 (Daniel DeLorme) wrote in <a href="#note-22">#note-22</a>:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Ah, that's a good point. <a class="user active user-mention" href="https://redmine.ruby-lang.org/users/13">@matz (Yukihiro Matsumoto)</a> what do you think?</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=963592022-02-03T09:59:52Zst0012 (Stan Lo)stan001212@gmail.com
<ul></ul><blockquote>
<p>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.</p>
</blockquote>
<p>I think it'll be fine but I'm not sure why the class name needs to be added as well?</p>
<p>And just for confirmation: so if I want to preserve the content of Ruby 3.1's <code>exception.message</code> (with additional information), I'll need to use <code>exception.detailed_message(highlight: false)</code> (without ANSI sequences)?</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=963612022-02-03T10:38:08Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>Thank you for your comment!</p>
<p>st0012 (Stan Lo) wrote in <a href="#note-24">#note-24</a>:</p>
<blockquote>
<p>I think it'll be fine but I'm not sure why the class name needs to be added as well?</p>
</blockquote>
<p>The current error printer inserts the exception class name.</p>
<pre><code>$ ruby -e 'raise "foo"'
-e:1:in `<main>': foo (RuntimeError)
</code></pre>
<p>This part <code>(RuntimerError)</code> is emphasized by an underline, so the method responsible for highlight should insert it. Now <code>Exception#detailed_message</code> has a responsibility to highlight the message, so it need to insert the class name.</p>
<pre><code>$ ./miniruby -e 'begin; raise "foo"; rescue; p $!.detailed_message; end'
"foo (RuntimeError)"
$ ./miniruby -e 'begin; raise "foo"; rescue; p $!.detailed_message(highlight: true); end'
"\e[1mfoo (\e[1;4mRuntimeError\e[m\e[1m)\e[m"
</code></pre>
<p>But I agree that this is not a big deal.</p>
<blockquote>
<p>And just for confirmation: so if I want to preserve the content of Ruby 3.1's <code>exception.message</code> (with additional information), I'll need to use <code>exception.detailed_message(highlight: false)</code> (without ANSI sequences)?</p>
</blockquote>
<p>Yes, you are right. More precisely, <code>exception.respond_to?(:detailed_message) ? exception.detailed_message : exception.message</code> would work. Note that <code>highlight</code> keyword is false by default.</p>
<p>If a feature to remove a class name is needed, maybe we need to write <code>exception.detailed_message(exception_class_name: false)</code> or something.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=963712022-02-03T14:06:05ZDan0042 (Daniel DeLorme)
<ul></ul><p>mame (Yusuke Endoh) wrote in <a href="#note-25">#note-25</a>:</p>
<blockquote>
<p>But I agree that this is not a big deal.</p>
</blockquote>
<p>Exactly. At this point it's kind of a bikeshed, it's just that according to <a href="#note-1">#note-1</a> Sentry displays the exception class above the message, so it would be displayed twice:</p>
<p><strong>NoMethodError</strong><br>
undefined method `[]' for nil:NilClass (NoMethodError)</p>
<p>So if <a class="user active user-mention" href="https://redmine.ruby-lang.org/users/11268">@st0012 (Stan Lo)</a> wants to parse out the "(NoMethodError)", might as well not show it by default, and use <code>detailed_message(exception_class_name: true)</code> in #full_message (the only place it's needed).</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=963782022-02-03T20:55:37Zst0012 (Stan Lo)stan001212@gmail.com
<ul></ul><blockquote>
<p>Now Exception#detailed_message has a responsibility to highlight the message, so it need to insert the class name</p>
</blockquote>
<p>I see. Thanks for the explanation!</p>
<blockquote>
<p>maybe we need to write exception.detailed_message(exception_class_name: false) or something.<br>
So if st0012 (Stan Lo) wants to parse out the "(NoMethodError)", might as well not show it by default, and use detailed_message(exception_class_name: true) in #full_message (the only place it's needed).</p>
</blockquote>
<p>I don't think adding another option just for that is necessary. I'll first display the <code>detailed_message</code> and if we receive any complain about the repeated class name, I'll remove it in the SDK.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=963992022-02-07T02:55:59Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>I talked with <a class="user active user-mention" href="https://redmine.ruby-lang.org/users/13">@matz (Yukihiro Matsumoto)</a>. He decided to go ahead with it as is, as it is not a serious problem.</p>
<p>If you want an exact compatibility with the traditional <code>Exception#message</code>, please remove a class name from detailed_message.</p>
<pre><code>exc = RuntimeError.new("foo\nbar\nbaz")
p exc.detailed_message #=> "foo (RuntimeError)\nbar\nbaz"
p exc.detailed_message.sub(/\A(.*?)(?: \(\w+\))/) { $1 } #=> "foo\nbar\nbaz"
</code></pre>
<p>We may consider adding a dedicated keyword argument for it if there are many requests.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=983302022-07-12T05:11:33Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>The following PR adds a guideline about usable escape sequences in <code>Exception#detailed_message</code>.</p>
<p><a href="https://github.com/ruby/ruby/pull/6119" class="external">https://github.com/ruby/ruby/pull/6119</a></p>
<p>Background:</p>
<p>An error message is primarily rendered in a terminal emulator, but is also shown in a browser by converting it to a HTML fragment, such as by Rack. However, the conversion would be unreasonably difficult if the message includes any escape sequence (such as cursor move or screen clear).</p>
<p>The safe and consertive way is to use <code>highlight: false</code>, but <a class="user active user-mention" href="https://redmine.ruby-lang.org/users/3344">@ioquatix (Samuel Williams)</a> suggested that we also want a way to convert the text attributes to HTML. (<a href="https://github.com/rack/rack/pull/1925#issuecomment-1179470336" class="external">https://github.com/rack/rack/pull/1925#issuecomment-1179470336</a>)<br>
I talked about the issue with <a class="user active user-mention" href="https://redmine.ruby-lang.org/users/13">@matz (Yukihiro Matsumoto)</a>, and we agreed to document a guideline for the use of escape sequences in <code>Exception#detailed_message</code>:</p>
<ul>
<li>Use only widely-supported escape sequences: bold, underline, and basic eight foreground colors (except white and black).</li>
<li>Make the message readable if all escape sequences are ignored.</li>
</ul>
<p>I think these limitations would make conversion to HTML easier.</p> Ruby master - Feature #18438: Add `Exception#additional_message` to show additional error informationhttps://redmine.ruby-lang.org/issues/18438?journal_id=992902022-09-23T08:01:06Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>I have already merged the PR. Closing.</p>