[#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:106942] [Ruby master Feature#18438] Add `Exception#additional_message` to show additional error information
From:
"Eregon (Benoit Daloze)" <noreply@...>
Date:
2022-01-01 11:49:08 UTC
List:
ruby-core #106942
Issue #18438 has been updated by Eregon (Benoit Daloze). @mame Thanks for making this proposal, I believe it goes in the right direction. Dan0042 (Daniel DeLorme) wrote in #note-6: > 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 That part, showing the exception class name, should be handled by `#full_message`, like it currently is. `description` would only return "a more complete message" but not try to do any formatting which is already handled by `#full_message` (like the exception class, backtrace, causes, etc). In fact, `full_message` is far more complicated than what is shown in @byroot's example (which is fine since it's illustrative). See https://github.com/oracle/truffleruby/blob/39d740bd3eb8abafe737656055850fc7b3a4d1dc/src/main/ruby/truffleruby/core/exception.rb#L90-L130 and https://github.com/oracle/truffleruby/blob/39d740bd3eb8abafe737656055850fc7b3a4d1dc/src/main/ruby/truffleruby/core/truffle/exception_operations.rb#L94-L112 for example. I think the `description` 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. Monitoring services can then just call `description(highlight: false)` instead of `message`. ---------------------------------------- Feature #18438: Add `Exception#additional_message` to show additional error information https://bugs.ruby-lang.org/issues/18438#change-95766 * 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:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>