L4 Smart Errors Laravel Package

Getting Started

Pull the package in with Composer from the project root:

composer require anlutro/l4-smart-errors

Register the service provider in app/config/app.php inside the providers array:

'providers' => array(
    // ...
    'Anlutro\L4SmartErrors\ServiceProvider',
),

Optionally publish the config file so you can tune behaviour per environment:

php artisan config:publish anlutro/l4-smart-errors

That drops a config into app/config/packages/anlutro/l4-smart-errors/config.php. Look there first — it's where the response format, view name, debug behaviour, and logging toggles live.

First use case: trigger any error from a route and hit it two ways. Open /your-route in a browser and you should get a rendered error view; hit the same route with curl -H "X-Requested-With: XMLHttpRequest" (or a Accept: application/json header) and you should get a structured JSON payload instead of an HTML page. That request-format awareness is the whole point of the package, so verify both paths before wiring it into anything else.

Implementation Patterns

Rely on auto-registration, not manual App::error. The service provider hooks into Laravel 4's error/fatal/missing handlers itself. Resist the urge to also call App::error() for the same cases unless you deliberately want to override the package — handlers run in registration order and the package's formatting can be masked by a later catch-all returning its own Response.

Let the package own the "shape" of the error, and you own the "content". In controllers and service classes, keep throwing normal exceptions:

if (!$post = Post::find($id)) {
    throw new NotFoundHttpException;
}

The package turns this into the right status code, view, and (for AJAX) JSON body. Your job is to throw domain-appropriate exceptions, not to hand-craft error responses.

Use it as the safety net for uncaught PHP errors. Laravel 4 only wires up App::error for exceptions; warnings and notices get swallowed or printed inline. The smart-errors handler sets an error handler so that stray E_WARNING/E_NOTICE from legacy or third-party code get logged and rendered through the same pipeline. That's most useful during a migration off an old codebase — you get one consistent error page instead of a half-rendered view with warnings leaking into the markup.

Custom views for branded errors. Point the config's view setting at something like errors.default and create app/views/errors/default.blade.php. Keep the template dumb — status, message, request ID — because it will render when the app is already in a bad state. Anything requiring a DB query or heavy auth check is a bad idea inside an error view.

Pair with App::missing for 404s. The package handles the render; you can still register an App::missing handler to do a redirect/rewrite or log the missing URL, then return null and let the package take over. This keeps your URL canonicalisation logic separate from your error formatting.

AJAX-aware workflows. If you're building a single-page-ish front end on Laravel 4, standardise on always sending X-Requested-With: XMLHttpRequest. Then your JS can have one error branch that parses { error: "..." } and knows it's getting the package's JSON shape, rather than sometimes HTML and sometimes JSON depending on the request headers.

Gotchas and Tips

Laravel 4 is EOL. This package is pinned to that era and hasn't seen a release in years. Use it if you're maintaining a legacy 4.x app — don't introduce it into anything new. If you're on 5.x or later, the same "format-aware error responses" job is better done with a small App\Exceptions\Handler override.

app.debug is the single most important knob. With debug on, you get full exception details and stack traces — great in dev, catastrophic in production. Verify both modes before shipping. The package is designed to respect app.debug, but confirm the error view you point at doesn't print raw exception output on its own.

Watch the error handler stacking. If another package (or a legacy bootstrap/start.php hook) also calls set_error_handler, whichever registers last wins. Symptoms: notices from your own code stop appearing, or errors are logged twice. Grep bootstrap/ and app/start/ for set_error_handler and App::error when behaviour looks off.

Config caching bites. Laravel 4 has no config:cache, but the packaged config path (app/config/packages/...) is easy to forget about. If a toggle isn't taking effect, php artisan config:publish may have created a file that shadows your defaults — check the packaged path first.

Fatal errors are best-effort. Out-of-memory and parse errors go through App::fatal, which can't guarantee a full render (memory, autoloader state). Keep fatal-mode view templates tiny and test with an actual ini_set('memory_limit', ...) exhaustion rather than a normal exception.

Logging is your audit trail. The handler logs details regardless of what it returns to the user. In production, rely on the log rather than a verbose page. If you're seeing empty log entries, confirm the log toggle in the package config wasn't turned off and that app/storage/logs is writable.

Debugging the handler itself: if errors disappear entirely, temporarily register your own App::error before the package's provider is booted and var_dump the exception. If it fires, the package is eating the response afterwards; if it doesn't, the exception never reached Laravel (a PHP fatal, or an early bootstrap error). That split isolates the problem quickly.

Extension point to remember: the exception-to-response decision lives in the package's handler classes. If you need a bespoke format (e.g. XML for a particular client), fork the response-building method via a subclass registered in your own provider rather than patching vendor code — composer update will overwrite the latter.