Weave Code
Error Handler Laravel Package
slick/error-handler
A Laravel error handler that centralizes exception handling, rendering, and reporting. Configurable handlers convert PHP exceptions into consistent responses, with hooks for logging, custom views, and per-type handling to keep error output predictable across your application.
slick/error-handler is a lightweight error handling package for Laravel/PHP applications that centralizes exception catching, rendering, and reporting. It provides a clean, consistent way to transform errors into user-friendly responses while preserving detailed context for logs and debugging.
- Pluggable exception renderers for JSON and HTML responses
- Centralized reporting hooks for logging and monitoring
- Configurable error views and HTTP status codes
- Context-aware payloads for API and web requests
- Simple published configuration via Laravel's config system
Frequently asked questions about Error Handler
- Is slick/error-handler a drop-in exception handler for Laravel?
- No. It is a Slick Framework module built around Slick's event dispatcher and HTTP abstractions, while Laravel uses Illuminate\Foundation\Exceptions\Handler. There is no natural seam where it plugs in; at best its formatter and renderer concepts are portable through an adapter.
- Does slick/error-handler integrate with Laravel's exception Handler?
- Not directly. Laravel's handler owns report() and render() and delegates to Symfony renderers, while slick/error-handler expects Slick wiring. Integration would require writing a bridge or isolating only a standalone formatter layer, which the evaluation describes as feasible but not free. Do not replace App\Exceptions\Handler without a timeboxed spike.
- How do I install slick/error-handler?
- The Composer package name is slick/error-handler, so installation starts with composer require slick/error-handler. Before adding it, check its PHP version constraints and any slick/* transitive requirements against your pinned Laravel stack. Because it is early-stage with no dependents, treat installation as a spike and review the source first.
- What Laravel and PHP versions does slick/error-handler support?
- The available evaluation does not list explicit Laravel version support, and the package is a Slick Framework module rather than a Laravel package. You need to inspect composer.json for the supported PHP range and any framework constraints, and check for CI evidence across versions. Composer resolution is a gate before this becomes more than a spike.
- Can I use slick/error-handler only for rendering and keep Laravel's reporting?
- That is the right question to ask, but the evaluation flags it as unresolved. If capture and rendering are separated and the formatter can map a Throwable to a payload standalone, you could keep Laravel's report() and use this only for presentation. If rendering is invoked by a Slick event listener, integration becomes a bidirectional bridge and loses its appeal.
- Does slick/error-handler depend on other Slick Framework packages?
- The evaluation says the module is designed to sit on top of Slick's event dispatcher and HTTP abstractions, so dependencies such as slick/event, slick/http, or PSR-7/PSR-15 are key unknowns. Check composer.json before assuming the formatter can be used standalone. If the renderer expects Slick's container and request/response objects, a Laravel adapter will be integration debt.
- Is slick/error-handler safe for production?
- The evaluation recommends consider, do not adopt for a Laravel codebase. It has zero stars and zero dependents, a single-maintainer bus factor, and no visible security disclosure process. Error handlers are security-sensitive because they decide how much stack trace, file path, and environment detail is exposed. Use it only behind a first-party interface and after a timeboxed spike.
- How does slick/error-handler handle verbose stack traces and environment gating?
- The available context does not confirm its defaults or gating mechanism. Because error handlers control how much debug detail becomes visible, you must verify whether verbose output is opt-in and how it is restricted per environment. Test that production never exposes stack traces or file paths before considering adoption.
- What are the alternatives to slick/error-handler in Laravel?
- Laravel's native Illuminate\Foundation\Exceptions\Handler, Symfony ErrorHandler, and services such as Sentry or Bugsnag already cover mainstream reporting and rendering with far more operational maturity. Historically Laravel also used Whoops or Ignition for local debug views. For most Laravel applications, those are better-supported choices than a Slick Framework module.
- Is slick/error-handler actively maintained and tested?
- The September 2024 release suggests recent activity, but there is no CI evidence in the evaluation and no public dependents exercising it against real workloads. It is a single-maintainer, single-package project, which is fragile for a component on the error path. Review the source, add your own tests, and keep a fork or vendoring path under MIT if upstream goes dormant.
Weaver
How can I help you explore Laravel packages today?