Laravel Queues in Action (2nd edition) is now available!

Reporting Exceptions

Updated: Jan 10, 2019 — 2 min Read#exception-handling

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 = [

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 = [

Built-in error reporting

Laravel is shipped with several error handling channels built on top of the Monolog library:

  1. Single log file: Logs exceptions into a storage/logs/laravel.log file.
  2. .Daily log files: Logs exceptions by creating daily log files inside storage/logs.
  3. Syslog.
  4. Error log: Logs exceptions into PHP's error log.
  5. Slack.
  6. Papertrail.
  7. 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:

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.

Hey! 👋 If you find this content useful, consider sponsoring me on GitHub.

You can also follow me on Twitter, I regularly post about all things Laravel including my latest video tutorials and blog posts.

By Mohamed Said

Hello! I'm a former Laravel core team member & VP of Engineering at Foodics. In this publication, I share everything I know about Laravel's core, packages, and tools.

You can find me on Twitter and Github.

This site was built using Wink. Follow the RSS Feed.