Code Happy: Debugging Applications

← Back to Index

Please note that this chapter was written for VERSION 3 of the Laravel PHP Framework.

Applications written using the Laravel framework are best experienced without bugs, however we all know how easily they can arise when we have deadlines to meet, and angry bosses standing over our shoulders.

PHP itself has a number of different methods of debugging, from simple var_dump()s, print_r()s, the famous die() and the advanced debugging features of the PHP xdebug extension. I'm not going to cover these basic methods in detail, because this is a book about Laravel, not the basics of the PHP language. Instead let's have a look at the features that Laravel offers to help us track down those mean little bugs.

Error Handler

Laravel includes a custom error handler, which overwrites the default one liner PHP errors, and instead provides some greater detail along with a stacktrace. Let's have a look at the output from the error handler..

Unhandled Exception


View [page.panda] doesn't exist.

/Users/daylerees/www/panda/laravel/view.php on line 151
Stack Trace:

#0 /Users/daylerees/www/panda/laravel/view.php(93): Laravel\View->path('page.panda')
#1 /Users/daylerees/www/panda/laravel/view.php(199): Laravel\View->__construct(' page.panda ', Array)
#2 /Users/daylerees/www/panda/application/routes.php(35): Laravel\View::make(' page.panda ')
#3 [internal function]: {closure}()
#4 /Users/daylerees/www/panda/laravel/routing/route.php(163): call_user_func_array(Object(Closure), Array)
#5 /Users/daylerees/www/panda/laravel/routing/route.php(124): Laravel\Routing\Route->response()
#6 /Users/daylerees/www/panda/laravel/laravel.php(125): Laravel\Routing\Route->call()
#7 /Users/daylerees/www/panda/public/index.php(34): require('/Users/dayleree...')
#8 {main}

This is the error that is shown if a requested view doesn't exist at run time. As you can see we have an informative error message from Laravel, as well as the file in which the error was encountered, and a line number. In addition we also have a stacktrace that shows the initial error, following all the method calls through the 'View' layer all the way down to the routing system.

Most of the time you won't need the stacktrace, but it could prove useful for the more experienced developers, for example when an error occurs within a complex library.

Error Configuration

We don't always want our errors to show in this way, especially on a production site where showing a stacktrace could pose a significant security risk.

Fortunately, and as always, Laravel has made it easy for us to change the configuration for the display of errors. The configuration file for the error reporting system can be found at application/config/error.php. Let's have a run through the configuration options that are contained in this array.

'ignore' => array(),

The ignore array contains a list of errors that are to be ignored by the error handler. Although these errors will no longer be displayed when they are encountered, they will always be logged. Keep this in mind when using the ignore array.

To add an error type to this array, add the PHP error type constant, or an integer value to the array.

'ignore' => array(E_ERROR);

A full list of PHP error type constants can be found on the PHP API, however here are some of the more useful ones.

E_ERROR This will match all fatal run time errors.

E_WARNING This constant will match all warning, or non fatal type errors.

E_PARSE This constant will match all parse time errors, or syntax errors.

E_NOTICE This constant will match all run time notices.

E_ALL This constant will match all of the above, except for E_STRICT errors.

'detail' => true,

The detail config option can be used to switch the detailed error reporting on or off. When enabled (true) it will show the full error report along with stack trace as shown above. Disabling this option (false) will cause the default error 500 page to be displayed instead.

'log' => false,

If the log config option is set to true, the closure contained within the logger config option will be executed with each error, and passed an exception object.

'logger' => function($exception)

By default, the closure contained within the logger config option will write an entry to a log file within the storage/logs. However, providing a closure has provided a great deal of flexibility, allowing you to override the default logging method with anything you can think of. Perhaps you would prefer to log to a database? Make it so number 1! Engage.


Being able to show errors, and log them to files is handy, but what if we want to log our own custom information? The Laravel Log class contains two different methods for logging useful information from your application. Let's take a look at these methods now.

The Log::write() method accepts a log type, and a string message to be written to the log file. For example..


Log::write('myapp', 'Here is some useful information.');

Will result in the following line being written to the log file.

2012-05-29 19:10:17 MYAPP - Here is some useful information.

The entry will of course be written to the active log file in the storage/logs directory in a file named after the current day, for example 2011-02-05.log. This allows for the logs to be rotated and avoid having log files that are huge!

You can also use a magic method to set the log type, for example..


Log::shoe('my log entry');

Will have the same effect as..


Log::write('shoe', 'my log entry');

Very useful!

Make use of all of the features you have learned in this chapter to diagnose your applications if anything goes wrong!

My books are available online for free to encourage learning. However, if you'd like for me to keep writing, then please consider buying a digital copy over at

It's available in PDF, ePub, and Kindle format, and contains a bunch of extras that you won't find on the site. I have a full-time job, and I write my books in my spare time. Please consider buying a copy so that I can continue to write new books from the comfort of my sofa!