Being able to track exceptions encountered inside your application is useful to understand what went wrong. Without any configuration from you, all exceptions are logged inside the storage/logs
directory organized into daily files. You can check these files at any point to know if anything went wrong with your application.
But sometimes I don't care if certain exceptions are thrown
Laravel is taking that into account, and before reporting any exception it checks if you really want it to be reported. In fact, laravel doesn't report certain exception types by default, like authentication and authorization exceptions for example.
You can find a list of all the ignored exception types in Illuminate\Foundation\Exceptions\Handler
protected $internalDontReport = [
AuthenticationException::class,
AuthorizationException::class,
HttpException::class,
HttpResponseException::class,
ModelNotFoundException::class,
TokenMismatchException::class,
ValidationException::class,
];
You can also define your own set of exceptions that you don't want to report; check the App\Exceptions\Handler
class and update the $dontReport
property:
class Handler extends ExceptionHandler
{
protected $dontReport = [
MyCustomException::class
];
}
Built-in error reporting
Laravel is shipped with several error handling channels built on top of the Monolog library:
- Single log file: Logs exceptions into a
storage/logs/laravel.log
file. - .Daily log files: Logs exceptions by creating daily log files inside
storage/logs
. - Syslog.
- Error log: Logs exceptions into PHP's error log.
- Slack.
- Papertrail.
- stderr.
There's also a special channel called "Stack", which allows you to use multiple channels at the same time, for example you can use daily log files and also report exceptions to Slack.
You can configure which log driver you wish to use by updating the config/logging.php
file.
What if I want to report exceptions in a different way?
You can do that in two ways:
- From within the
report()
method of yourApp\Exceptions\Handler
class you can integrate your own reporting mechanism, this method is called whenever an exception should be reported and it's a good place for that kind of custom reporting - Or you can define a
report()
method in your custom exception and define your own reporting mechanism there.
If you're going to take the first approach then make sure you call parent::report($exception)
inside the report()
method. The parent method holds the logic for checking if the exception should be reported or not and handles calling the report()
method of custom exceptions.
If you want to take full control of how exceptions are reported, you can stop calling parent::report($exception)
and do your own thing but make sure you take a look at the logic inside that parent method to see how it works.
In case you implement a report()
method inside a custom exception you have to be aware that this exception won't be logged in the log files, the Exception handler skips this step once a report()
method is found on the exception class.
If you have any questions or find parts that need more clarification, please let me know. I'm going to update the post with more information based on the feedback I receive.