Allow overriding the default log message or report behavior

[kewne]

When an exception bubbles up to the the Laravel exception handler, the following code in reportThrowable is called:

method_exists($logger, $level)
            ? $logger->{$level}($e->getMessage(), $context)
            : $logger->log($level, $e->getMessage(), $context);

My suggestion is to, instead, allow the developer to provide a default log message:

method_exists($logger, $level)
            ? $logger->{$level}($this->defaultErrorMessage ?? $e->getMessage(), $context)
            : $logger->log($level, $this->defaultErrorMessage ?? $e->getMessage(), $context);

When using a log aggregation system, we alert on logs with ERROR level.
This sometimes produces too many alerts, so we group logs with the same message before firing the alert.
However, this doesn't work well with the default logging behavior because the exception messages contain very specific information, e.g.:

• the SQL query that was attempted
• the URL and method for the HTTP request
• some parameters relevant to the context where the exception was thrown

The way we currently deal with this is we have overridden the reporting for every specific exception we see. This is not ideal because we have to remember to do this for every new exception, otherwise we might get an alert flood

We've also considered overriding the entire handler but reportThrowable has the exception level and exception context logic that we'd have to replicate in our implementation and maintain for framework updates.
It would be better if the framework provided out of the box.

[Pola5h]

Hey, I think the problem with a single $defaultErrorMessage on the handler is that it's too blunt. You'd end up with every exception logging the same static string, which trades alert floods for undiagnosable logs.

A more composable approach would be to allow individual exception classes to declare a loggableMessage() method, similar to how report() already works:

class MyException extends \Exception
{
    public function loggableMessage(): string
    {
        return 'Database query failed';
    }
}

The handler checks for this method before falling back to $e->getMessage(). Keeps the customization close to the exception, fits existing conventions, and you don't have to remember to register anything globally.

[shaedrich]

Alternatively to @Pola5h's solution, there could be a groupBy() method on the exception handler similar to the uniqueBy() method on jobs and to how tools like Sentry handle error grouping

[Pola5h]

Fair point @shaedrich, groupBy() handles vendor exceptions better, which is a real gap in my suggestion. I'd still keep loggableMessage() as a convention for your own exception classes since it keeps the logic close to the exception itself. But groupBy() should probably be the primary solution here since it works universally without touching exception classes.

[shaedrich]

I think, they can neatly combined by groupBy() falling back to loggableMessage() if the latter is defined and the former is not overwritten and no additional grouping logic is needed in groupBy().