Open jwpage opened 1 week ago
Hi @jwpage,
Thanks for your feedback.
We have raised this with our engineers for discussion, and we will be sure to let you know of any updates.
Hi @jwpage,
We would expect logged errors be reported as handled errors for the Laravel notifier. Are you able to provide code snippets of exactly how you are logging/triggering these errors that are appearing as unhandled in the dashboard, and more details about the logger you are using? Please feel free to write in to us at support@bugsnag.com if you would rather not share these code snippets publicly.
Description
Currently the only way to report a handled exception is via
Bugsnag::notifyException
.I feel that exceptions that are raised via
rescue/report/report_if/report_unless()
should also be considered handled, as this is explicit code from the developer to notify the framework of an exception.Likewise, errors reported directly via the logger would be considered handled as code like
logger()->error('oh no')
is explicit code from the developer, which indicates they are already aware of the error.I think that only truly unhandled exceptions - ie. a loose
throw $someException
(not from the above methods) that makes it all the way to the Laravel exception handler - should be marked as "unhandled".This ticket is mostly a discussion about whether alternative methods of reporting handled exceptions should be considered.
Describe the solution you'd like Introduce a new major version of bugsnag-laravel (as to change it on the same version would have repercussions for developers using the above methods), that marks exceptions from the above methods as "handled" instead of "unhandled". I imagine this would happen inside the
BacktraceProcessor
but have yet to fully look into it. I'd be happy to investigate further if this change is desired.Describe alternatives you've considered The most obvious alternative is to simply use
Bugsnag::notifyException()
but I think it is more idiomatic to use framework-provided helpers for reporting handled exceptions, which also makes it easier for people who aren't using Bugsnag to move across to Bugsnag without modifying existing code.The other alternative is to replace the existing
report
(etc) helpers with my ownreport
(etc) helpers to do, in order: send aBugsnag::notfiyException()
, disable Bugsnag, fallback to the original exception handler, and then finally re-enable Bugsnag - though this seems like more effort than it's worth!Anyway, let me know what you think 😄