Unhandled vs Handled Exceptions from framework helpers

[jwpage]

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 own report (etc) helpers to do, in order: send a Bugsnag::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 😄