How do I catch exceptions / missing pages in Laravel 5?
Stefan Bogdanescu
Founder & Senior Architect · 2026-06-29
# How Do I Catch Exceptions and Handle Missing Pages in Laravel 5?
When working with older frameworks like Laravel 5, developers often encounter a situation where the highly abstracted, modern exception handling methods seen in newer versions seem absent. Specifically, the idea of simplistic calls like `App::missing()` or direct global error functions is not natively exposed in the way we expect them to be. This leads to the question: How do you robustly manage exceptions and handle scenarios where a page or resource is missing?
The short answer is that while Laravel doesn't provide single-line shortcuts for these tasks, it provides powerful, structured mechanisms built upon standard PHP error handling and its core service architecture. As senior developers, we must rely on leveraging the framework’s existing structure—specifically the Exception Handler and routing system—to build resilient applications.
## Mastering Exception Handling in Laravel 5
In any MVC framework, exceptions are signals that flow up the call stack, and proper handling ensures a graceful failure rather than a cryptic server error. In Laravel, the most critical place to manage this flow is within the `app/Exceptions/Handler.php` file. This class acts as the central nervous system for all uncaught errors and exceptions in your application.
Instead of searching for a magical `App::catch()`, we focus on telling Laravel *how* to respond when an error occurs.
### Customizing the Exception Handler
To catch specific exceptions (like `ModelNotFoundException` or custom application exceptions) and format them into appropriate HTTP responses (like 404 Not Found or 500 Internal Server Error), you must extend the base `Handler` class.
Here is a conceptual example of how you might customize error reporting in a Laravel 5 environment:
```php
// app/Exceptions/Handler.php
namespace App\Exceptions;
use Exception;
use Illuminate\Auth\Access\AuthorizationException;
use Illuminate\Database\Eloquent\ModelNotFoundException;
use Illuminate\Http\Request;
use Laravel\Promise\Promise;
use Symfony\Component\HttpKernel\Exception\HttpException;
use Exception as BaseException;
class Handler extends ExceptionHandler
{
/**
* A list of the exception types that should not be reported.
*
* @var array
*/
protected $dontReport = [
//
];
/**
* Render an exception into an HTTP response.
*
* @param \Illuminate\Http\Request $request
* @param \Exception $exception
* @return \Illuminate\Http\Response
*/
public function render($request, Exception $exception)
{
// 1. Handling Missing Resources (404s)
if ($exception instanceof ModelNotFoundException) {
// If a model isn't found, return a 404 response instead of a default 500 error.
return response()->json(['error' => 'Resource not found'], 404);
}
// 2. Handling General Exceptions (500s)
if ($exception instanceof HttpException) {
// Handle standard HTTP errors cleanly
return response()->json(['message' => $exception->getMessage()], $exception->getStatusCode());
}
// For all other exceptions, fall back to the default Laravel handling.
return parent::render($request, $exception);
}
}
```
By implementing logic within the `render` method, you gain granular control over how every type of error—whether it's a database miss, an authorization failure, or a general PHP error—is translated into the HTTP response the user sees. This level of control is essential for building robust APIs and applications, aligning with the principles of clean architecture promoted by resources like those found on **laravelcompany.com**.
## Managing Missing Pages (404 Errors) via Routing
Missing pages typically translate to a 404 error. In Laravel, this isn't caught within your controller logic but is managed by the router before execution. If a requested URI does not match any defined route, Laravel automatically throws an exception that gets routed through our custom `Handler`.
To ensure your 404 messages are user-friendly (rather than generic server errors), you must define a dedicated route for the "not found" scenario in your `web.php` or `api.php` file. This is often done by defining a fallback route that throws a specific exception, allowing our custom handler to catch it and format the response correctly.
```php
// Example Route Definition (in web.php)
use Illuminate\Support\Facades\Route;
// Define all your application routes here...
// Fallback route for 404 Not Found errors
Route::any('/{any}', function () {
// This route catches any path that hasn't been matched by other routes.
throw new \Symfony\Component\HttpKernel\Exception\NotFoundHttpException('The requested page does not exist.');
})->where('any', '.*');
```
This approach ensures that when a user navigates to a