mf

Exception Handling in Laravel

In this article, we’re going to explore one of the most important and least discussed features of the Laravel web framework—exception handling. Laravel comes with a built-in exception handler that allows you to report and render exceptions easily and in a friendly manner.

In the first half of the article, we’ll explore the default settings provided by the exception handler. In fact, we’ll go through the default Handler class in the first place to understand how Laravel handles exceptions.

In the second half of the article, we’ll go ahead and see how you could create a custom exception handler that allows you to catch custom exceptions.

Setting Up the Prerequisites

Before we go ahead and dive into the Handler class straight away, let’s have a look at a couple of important configuration parameters related to exceptions.

Go ahead and open the config/app.php file. Let’s have a close look at the following snippet.

As the name suggests, if it’s set to TRUE, it’ll help you to debug errors that are generated by an application. The default value of this variable is set to a value of the APP_DEBUG environment variable in the .env file.

In the development environment, you should set it to TRUE so that you can easily trace errors and fix them. On the other hand, you want to switch it off in the production environment, and it’ll display a generic error page in that case.

In addition to displaying errors, Laravel allows you to log errors in the log file. Let’s have a quick look at the options available for logging. Again, let’s switch to the config/app.php file and have a close look at the following snippet.

As Laravel uses the Monolog PHP library for logging, you should set the above options in the context of that library.

The default log file is located at storage/logs/laravel.log, and it’s sufficient in most cases. On the other hand, the APP_LOG_LEVEL is set to a value that indicates the severity of errors that’ll be logged.

So that was a basic introduction to the configuration options available for exceptions and logging.

Next, let’s have a look at the default Handler class that comes with the default Laravel application. Go ahead and open the app/Exceptions/Handler.php file.

There are two important functions that the handler class is responsible for—reporting and rendering all errors.

Let’s have a close look at the report method.

The report method is used to log errors to the log file. At the same time, it’s also important to note the dontReport property, which lists all types of exceptions that shouldn’t be logged.

Next, let’s bring in the render method.

If the report method is used to log or report errors, the render method is used to render errors on a screen. In fact, this method handles what will be displayed to users when the exception occurs.

The render method also allows you to customize a response for different types of exceptions, as we’ll see in the next section.

Finally, the unauthenticated method handles the AuthenticationException exception that allows you to decide what will be displayed to users in case they’re unauthenticated to access a page they are looking for.

Custom Exception Class

In this section, we’ll create a custom exception class that handles exceptions of the CustomException type. The idea behind creating custom exception classes is to easily manage custom exceptions and render custom responses at the same time.

Go ahead and create a file app/Exceptions/CustomException.php with the following contents.

The important thing to note here is that the CustomException class must extend the core Exception class. For demonstration purposes, we’ll only discuss the render method, but of course you could also customize the report method.

As you can see, we’re redirecting users to the errors.custom error page in our case. In that way, you can implement custom error pages for specific types of exceptions.

Of course, we need to create an associated view file at resources/views/errors/custom.blade.php.

That’s a pretty simple view file that displays an error message, but of course you could design it the way you want it to be.

We also need to make changes in the render method of the app/Exceptions/Handler.php file so that our custom exception class can be invoked. Let’s replace the render method with the following contents in the app/Exceptions/Handler.php file.

As you can see, we are checking the type of an exception in the render method in the first place. If the type of an exception is AppExceptionsCustomException, we call the render method of that class.

So everything is in place now. Next, let’s go ahead and create a controller file at app/Http/Controllers/ExceptionController.php so we can test our custom exception class.

Powered by WPeMatico

Leave a Comment

Scroll to Top