-
-
Notifications
You must be signed in to change notification settings - Fork 494
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Exception#detailed_message
when generating exception message if applicable
#1924
Conversation
Codecov ReportBase: 98.45% // Head: 98.41% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #1924 +/- ##
==========================================
- Coverage 98.45% 98.41% -0.05%
==========================================
Files 151 151
Lines 9259 9273 +14
==========================================
+ Hits 9116 9126 +10
- Misses 143 147 +4
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
…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
@@ -103,7 +103,7 @@ | |||
expect(response.status).to eq(500) | |||
|
|||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
highlight: false
removes ANSI escape code that's mainly for standard output.#detailed_message
always returns a string. Even if the exception's message isnil
, it still returns"(Exception)"
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.