You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PSR-3 offers several criticality levels. It would be really nice, if the current \Illuminate\Foundation\Exceptions\Handler could make it easier to utilize per exception.
After all, some exceptions are more critical than others - if at all critical.
This could be as easy as stating an array, containing the exception's namespace as the key, and a log level as the value.
The name of the class property is not well considered, in the shown example - nor is it that important, in this context.
Default Behavior
Unless a custom criticality level is specified for the current caught exception, then it should just be logged as LogLevel::ERROR (current behavior of Laravel's default exception handler). Logging must of course continue to respect the current $dontReport behavior, ...etc.
Workaround
In the current Laravel version, developers need to make use of reportable() mechanism, perform desired logging, and stop the propagation, to avoid the default logging from creating a dual entry.
Alternatively, developers must overwrite the report() method and customize it.
Both alternative approaches are doable. But, it is a bit cumbersome.
The proposed solution SHOULD NOT break any current functionality of the default exception handler (at least none that I can think of).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
PSR-3 offers several criticality levels. It would be really nice, if the current
\Illuminate\Foundation\Exceptions\Handler
could make it easier to utilize per exception.After all, some exceptions are more critical than others - if at all critical.
This could be as easy as stating an array, containing the exception's namespace as the key, and a log level as the value.
Example
The name of the class property is not well considered, in the shown example - nor is it that important, in this context.
Default Behavior
Unless a custom criticality level is specified for the current caught exception, then it should just be logged as
LogLevel::ERROR
(current behavior of Laravel's default exception handler). Logging must of course continue to respect the current$dontReport
behavior, ...etc.Workaround
In the current Laravel version, developers need to make use of
reportable()
mechanism, perform desired logging, and stop the propagation, to avoid the default logging from creating a dual entry.Alternatively, developers must overwrite the
report()
method and customize it.Both alternative approaches are doable. But, it is a bit cumbersome.
The proposed solution SHOULD NOT break any current functionality of the default exception handler (at least none that I can think of).
Beta Was this translation helpful? Give feedback.
All reactions