[#107008] [Ruby master Bug#18465] Make `IO#write` atomic. — "ioquatix (Samuel Williams)" <noreply@...>
Issue #18465 has been reported by ioquatix (Samuel Williams).
16 messages
2022/01/09
[#107150] [Ruby master Feature#18494] [RFC] ENV["RUBY_GC_..."]= changes GC parameters dynamically — "ko1 (Koichi Sasada)" <noreply@...>
Issue #18494 has been updated by ko1 (Koichi Sasada).
4 messages
2022/01/17
[#107170] Re: [Ruby master Feature#18494] [RFC] ENV["RUBY_GC_..."]= changes GC parameters dynamically
— Eric Wong <normalperson@...>
2022/01/17
> https://bugs.ruby-lang.org/issues/18494
[#107302] [Ruby master Bug#18553] Memory leak on compiling method call with kwargs — "ibylich (Ilya Bylich)" <noreply@...>
Issue #18553 has been reported by ibylich (Ilya Bylich).
4 messages
2022/01/27
[#107346] [Ruby master Misc#18557] DevMeeting-2022-02-17 — "mame (Yusuke Endoh)" <noreply@...>
Issue #18557 has been reported by mame (Yusuke Endoh).
18 messages
2022/01/29
[ruby-core:107388] [Ruby master Feature#18438] Add `Exception#additional_message` to show additional error information
From:
"mame (Yusuke Endoh)" <noreply@...>
Date:
2022-01-31 10:31:20 UTC
List:
ruby-core #107388
Issue #18438 has been updated by mame (Yusuke Endoh).
I talked with @matz and @nobu about that.
The current implementation of `Exception#full_message` adds `\e[1m` (i.e., bold start) for each beginning of line of `#message`, and `e[m` (i.e., bold end) for each end. (Also, it adds `" (RuntimeError)"` or something to the last of the first line.)
With that in mind, `#detailed_message` can freely add their own escape sequences. `Exception#full_message` won't check the result of `detailed_message`.
BTW, the behavior of `Exception#full_message` (adding `\e[1m` and `e[m`) will be moved to `Exception#detailed_message`. That is, a rough spec will be like the following.
```
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
```
Note that the "addtional message" part of `MyError#detailed_message` will not be automatically highlighted.
----------------------------------------
Feature #18438: Add `Exception#additional_message` to show additional error information
https://bugs.ruby-lang.org/issues/18438#change-96292
* 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>