In Laravel 13, which exceptions does the handler never report by default, and how do dontReport, ShouldntReport and stopIgnoring change that?

## Why some exceptions are never reported Many exceptions in a Laravel app are **control flow**, not faults: a validation failure becomes a 422, a missing model becomes a 404, a guest hitting a protected page is redirected to login. Logging them would bury real errors, so the handler checks every exception against ignore rules before it reports anything. Ignoring affects **reporting only**; the exception is still rendered into its normal response. ## The internal list in Laravel 13 The handler's `$internalDontReport` property holds these classes, matched with `instanceof`, so subclasses count: | Class | Typical source | |---|---| | `Symfony\...\HttpException` | `abort()` with any status, `NotFoundHttpException` for unknown routes | | `Illuminate\Http\Exceptions\HttpResponseException` | Code that throws a ready-made response | | `Illuminate\Validation\ValidationException` | Failed validation | | `Illuminate\Auth\AuthenticationException` | Unauthenticated request | | `Illuminate\Auth\Access\AuthorizationException` | A denied gate or policy | | `ModelNotFoundException`, `RecordNotFoundException`, `RecordsNotFoundException` | `findOrFail()`, route model binding misses | | `Illuminate\Session\TokenMismatchException` | A 419 from a missing or stale CSRF token | | `Illuminate\Http\Exceptions\OriginMismatchException` | A cross-origin request rejected by `PreventRequestForgery` | | `BackedEnumCaseNotFoundException` | An enum route parameter with an unknown value | | Symfony `RequestExceptionInterface` | Malformed or suspicious requests | The first row has a trap: because the whole `HttpException` class is ignored, `abort(500, 'Payment backend down')` produces **no log entry**. Throw a real exception when you want a server fault recorded. ## Adding your own rules Three tools extend the list, all in `bootstrap/app.php` or on the class: - **`$exceptions->dontReport(SmsQuotaExceededException::class)`** accepts a class name or an array and adds it to the application's list. - **`$exceptions->dontReportWhen(fn (Throwable $e) => ...)`** registers a closure; the exception is skipped when it returns exactly `true`. Use it for conditions a class name cannot express, such as a status code or a reason field. - **`Illuminate\Contracts\Debug\ShouldntReport`** is a marker interface with no methods. An exception that implements it is never reported, and the decision travels with the class. ## Removing entries with stopIgnoring() `$exceptions->stopIgnoring(...)` takes a class name or an array and removes those names from both the application list and the internal list. The removal is an **exact string match** against the list entries, while the ignore check itself uses `instanceof`. That combination means: 1. `stopIgnoring(NotFoundHttpException::class)` changes nothing, because the list holds its parent `HttpException`, which still matches. 2. `stopIgnoring(HttpException::class)` re-enables reporting for **every** HTTP exception, 404s and 403s included. 3. To report only server-side aborts, pair it with a condition: ```php $exceptions->stopIgnoring(HttpException::class); $exceptions->dontReportWhen( fn (Throwable $e) => $e instanceof HttpException && $e->getStatusCode() < 500 ); ``` `stopIgnoring()` does not touch `ShouldntReport`: the interface is checked separately, so a class that implements it stays unreported whatever the lists say. ## Choosing between the tools | Tool | Where it lives | Best for | |---|---|---| | `dontReport([...])` | `bootstrap/app.php` | Third-party or framework classes you cannot edit | | `ShouldntReport` | On your exception class | Your own expected failures; the rule travels with the class | | `dontReportWhen(fn ...)` | `bootstrap/app.php` | Conditions: a status code, a reason code, an environment | | `stopIgnoring([...])` | `bootstrap/app.php` | Undoing a built-in or earlier ignore entry | A useful review question for each entry is "would an operator act on this?". An expected business outcome, such as a customer who opted out of SMS, is not operator signal and belongs on an ignore rule; a provider rejecting every message because an API key expired is signal and must never be silenced by a broad `dontReport` on the gateway's base exception class. ## How the checks are ordered Before reporting, the handler runs deduplication (when enabled), then `ShouldntReport`, then the combined lists, then `dontReportWhen` closures, then `throttle()`. An exception rejected at any step skips the exception's own `report()` method, every report callback and the logger. ## Common mistakes - Expecting `abort(500)` to appear in the log. - Calling `stopIgnoring()` on a subclass of a listed class. - Returning a truthy non-boolean from `dontReportWhen`; only `true` skips. - Assuming an ignored exception also gets a blank or default response; rendering is unaffected.