Use Exception#detailed_message when generating exception message if applicable #1924
Use Exception#detailed_message when generating exception message if applicable #1924
Exception#detailed_message when generating exception message if applicable #1924Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1924 +/- ##
==========================================
- Coverage 98.45% 98.43% -0.02%
==========================================
Files 151 151
Lines 9259 9273 +14
==========================================
+ Hits 9116 9128 +12
- Misses 143 145 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…pplicable
Ruby 3.1 provided more detailed exception messages like
```
undefined method `[]' for nil:NilClass
{}[:foo][:bar]
^^^^^^
```
But the additional information was put directly input `Exception#message`, which caused some problems
(as described in [this ticket](https://bugs.ruby-lang.org/issues/18438)).
So in Ruby 3.2, the additional message will be put into the `Exception#detailed_message`,
which as a error monitoring service is what we should use.
64a96bf to
1c4888f
Compare
|
|
||
| expect(event["exception"]["values"][0]["type"]).to eq("RuntimeError") | ||
| expect(event["exception"]["values"][0]["value"]).to eq("An unhandled exception!") | ||
| expect(event["exception"]["values"][0]["value"]).to match("An unhandled exception!") |
There was a problem hiding this comment.
#detailed_message always includes (ExceptionClass), which I think is beneficial and should be kept.
But I also don't want to check Ruby version before every message check, so I just switch to match instead.
|
cc @mame |
| @value = (exception.message || "").byteslice(0..Event::MAX_MESSAGE_SIZE_IN_BYTES) | ||
| exception_message = | ||
| if exception.respond_to?(:detailed_message) | ||
| exception.detailed_message(highlight: false) |
There was a problem hiding this comment.
highlight: falseremoves ANSI escape code that's mainly for standard output.#detailed_messagealways returns a string. Even if the exception's message isnil, it still returns"(Exception)".
sl0thentr0py
left a comment
There was a problem hiding this comment.
nice! the only (negligible) concern I have is if this somehow affects grouping?
But I think it should be fine, let's merge it.
Ruby 3.1 provided more detailed exception messages like
But the additional information was put directly input
Exception#message, which caused some problems (as described in this ticket).So in Ruby 3.2, the additional message will be put into the
Exception#detailed_message(proposal), which as a error monitoring service is what we should use.