Renderizar es lo que ve el cliente. Reportar es lo que ves tú: el log, el rastreador de errores, la alerta que despierta a alguien.
Laravel ya ignora las excepciones que son un error del consumidor y no tuyo. Los fallos de validación, los fallos de autenticación, los 404 y el throttle nunca se reportan. Esa lista no la escribes tú.
Lo que añades son los fallos que se esperan en tu sistema:
// bootstrap/app.php
$exceptions->dontReportDuplicates();
$exceptions->level(
ConnectionException::class,
LogLevel::WARNING,
);
Un timeout del proveedor merece saberse y no merece despertar a nadie, así que se registra como un aviso. Cuando el proveedor está caído una hora, tampoco merece diez mil entradas idénticas: $exceptions->throttle() recibe un límite y reporta como mucho ese número de veces una misma excepción por minuto. (Documentación de Laravel: Error Handling › Throttling Reported Exceptions.) Para una excepción que es puro flujo de control, como un job que dice «todavía no está listo, inténtalo otra vez», implementa ShouldntReport en la clase y no se reporta nunca:
// app/Exceptions/NotReadyYet.php
class NotReadyYet extends Exception implements ShouldntReport
{
//
}
Ningún if en un callback de reporte, y ningún ruido que ahogue las excepciones que necesitan a una persona.
No llames a tu rastreador de errores a mano
Un rastreador de errores, sea Nightwatch, Sentry o Flare, se registra en el manejador de excepciones de Laravel cuando lo instalas. Toda excepción reportada le llega. No necesitas enviar nada. Un ajuste sí es tuyo: haz que limpie la cabecera Authorization, o cada reporte llevará un token válido al almacenamiento de otro.
Eso lo aprendí por las malas. Un callback de reporte que escribí llamaba al rastreador directamente, con una rama por tipo de excepción para fijar la severidad, y envolvía las llamadas en try/catch (Throwable) para que una caída del rastreador nunca pudiera romper una petición. Los métodos a los que llamaba no existían en la facade de ese rastreador. Cada llamada lanzaba una excepción. El catch se la tragaba. Mientras ese código estuvo en marcha, la lógica de severidad que había escrito no hizo nada, y nada me avisó, porque lo único construido para atrapar un fallo silencioso era lo que fallaba en silencio.
El rastreador había estado recibiendo todas las excepciones de todos modos, por su propio gancho. El callback era innecesario desde el principio.
Lo que saqué de ahí: usa level(), dontReport() y ShouldntReport para dar forma al reporte, y deja que el rastreador escuche. Y trata un catch (Throwable) vacío como un bug hasta que se demuestre lo contrario.