Custom exception handling in Laravel Zero cover image

Custom exception handling in Laravel Zero

4 min readJanuary 12, 2019

laravel-zero tutorials php

One of my goals this year is contributing back to the open source community. As I'm currently looking into Laravel Zero for automating some things, I thought that that project would be a great start to contributing back.

As I was looking at the issues on GitHub an issue popped up where I thought I could help out with documenting the necessary steps to solve that issue. The gist of that issue is not being able to prevent certain exceptions being reported to the end user.

So I wrote the Exception Handler documentation and made a pull request. That got merged, so I guess I'm off to a good start.

Even though the documentation is good enough to get you started, sometimes you revisit your code and think this could be written just a bit better. The example in the documentation only touched the subject of the RunTimeException that was the problem in the issue that started it all.

But what if we want to add other messages or more exceptions that don't need reporting when the built phar is run?

What we will make

The result will still be the same as the solution to the issue, not showing the output of the RunTimeException when a command is running from the built phar file. We will however make the exception handler a bit more flexible, so you can add other exceptions more easily.

This article assumes you are using Laravel Zero 5.7, you have your app up and running and created the custom exception handler as seen in the official documentation.

Adding extra sauce

To make the exception handler more flexible we will be adding an extra property to the class where we will group the exceptions, similar to the $dontReport property.

What we want to do is add exceptions and the possible strings to look for when deciding to report or not report an exception to that property so you only have to maintain that property and not the report function.

Adding the property

I decided to use a $dontReportMessages property and added that to the App\Exceptions\Handler class. Paste the content below beneath the $dontReport property.

    /**
     * A list of the exception types that should not be reported if they contain certain messages
     * 
     * @var array 
     */
    protected $dontReportMessages = [

    ];

This property will contain exception classes as keys and messages we don't want to report as a value array of those keys. If we go back to our example in the documentation and add the message we had there to the $dontReportMessage property we get the following code.

    /**
     * A list of the exception types that should not be reported if they contain certain messages
     * 
     * @var array 
     */
    protected $dontReportMessages = [
        RuntimeException::class => [
            'Not enough arguments',
        ],
    ];

Don't forget to add use Symfony\Component\Console\Exception\RuntimeException; at the top of your file after the other use statements if needed or use the fully qualified name here instead.

Updating the report function

Now that we have our property it's time to update the report function to use that property. This is the current version as in the last example of the official documentation.

public function report(Exception $exception)
{
    if (\Phar::running()) {
        if ($exception instanceof RuntimeException) {
            if (Str::contains($exception->getMessage(), ['Not enough arguments'])) {
                return;
            }
        }
    }

    parent::report($exception);
}

Lets change that so we use our new $dontReportMessages property.

public function report(Exception $exception)
{
    if (\Phar::running()) {
        foreach($this->dontReportMessages as $type => $messages) {
            if($exception instanceof $type) {
                if(Str::contains($exception->getMessage(), $messages)) {
                    return;
                }
            }
        }
    }

    parent::report($exception);
}

With this change we can add more exceptions and messages to the $dontReportMessages property and they won't get reported when run from the built phar file.

Other things to consider

While the above changes made the Handler just a bit more flexible, you can abstract things further, but I'll leave that up to you. I will however give you a few pointers to things you could abstract: