[#106341] [Ruby master Bug#18369] users.detect(:name, "Dorian") as shorthand for users.detect { |user| user.name == "Dorian" } — dorianmariefr <noreply@...>
Issue #18369 has been reported by dorianmariefr (Dorian Mari辿).
14 messages
2021/11/30
[#106351] [Ruby master Bug#18371] Release branches (release information in general) — "tenderlovemaking (Aaron Patterson)" <noreply@...>
Issue #18371 has been reported by tenderlovemaking (Aaron Patterson).
7 messages
2021/11/30
[ruby-core:106051] [Ruby master Bug#18296] Custom exception formatting should override `Exception#full_message`.
From:
"Eregon (Benoit Daloze)" <noreply@...>
Date:
2021-11-14 12:40:48 UTC
List:
ruby-core #106051
Issue #18296 has been updated by Eregon (Benoit Daloze).
mame (Yusuke Endoh) wrote in #note-13:
> Also, the motivation of this proposal is not clear to me.
Some important motivation is explained in https://bugs.ruby-lang.org/issues/18296#note-4:
* Callers can choose whether they want `did_you_mean/error_highlight` (individually) in the exception message or not, and they have a way to get the original exception message (just `Exception#message` would be the original message).
* It makes it possible to choose more dynamically than global --disable-`did_you_mean/error_highlight`. Given e.g. error_highlight has a non-trivial performance impact, it seems useful to be able only get this output in some situations where the caller might know whether it is useful.
* `did_you_mean/error_highlight` can find out about options given to `full_message` such as `highlight:`, or even introduce their own additional options (keyword arguments).
For instance `error_highlight` could use `highlight:` to decide whether to use ANSI sequences to colorize the failing call, or to use `^^^^` on the next line (I know @ioquatix cares about this flexibility).
This can be useful e.g. to have different output for Exception#inspect (don't want ANSI escape sequences, and probably not extra information) and printing the exception to a terminal (all information and ANSI escape sequences). Some test harness might choose different trade-offs, and this lets them choose.
* It's a cleaner integration than overriding `#message`, it can allow more gems to customize exceptions and there is no problem if some exception subclasses override `#message`.
I agree it would be best to reopen a ticket with everything needed in the description.
I think mostly we need a better name than `message_with_extras` in https://bugs.ruby-lang.org/issues/18296#note-9.
Maybe `#decorated_message`?
Also if you have any feedback on https://bugs.ruby-lang.org/issues/18296#note-9 that would be useful to make a better proposal.
----------------------------------------
Bug #18296: Custom exception formatting should override `Exception#full_message`.
https://bugs.ruby-lang.org/issues/18296#change-94638
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
After discussing with @eregon, we came to the conclusion that the current implementation of `did_you_mean` and `error_highlight` could avoid many issues by using `Exception#full_message`.
We propose to introduce a more nuanced interface:
```ruby
class Exception
def full_message(highlight: bool, order: [:top or :bottom], **options)
# ...
end
end
module DidYouMean
module Formatter
def full_message(highlight:, did_you_mean: true, **options)
buffer = super(highlight: highlight, **options).dup
buffer << "extra stuff"
end
end
end
Exception.prepend DidYouMean::Formatter
module ErrorHighlight
module Formatter
def full_message(highlight:, error_highlight: true, **options)
# same as above
end
end
end
Exception.prepend ErrorHighlight::Formatter
```
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>