Weave Code
Exception Laravel Package
illuminate/exception
The exception handling component of Laravel, providing the Handler that catches, reports, and renders exceptions into HTTP responses. It supports custom render and report logic, HTTP exceptions, and clean error output across your application.
[READ ONLY] Subtree split of the Illuminate Exception component (see laravel/framework)
Frequently asked questions about Exception
- What is illuminate/exception used for?
- It is the exception handling component of Laravel, providing the Handler that catches, reports, and renders exceptions into HTTP responses. It supports custom report and render logic, HTTP exceptions, and clean error output. In practice it is the engine behind the error handling you already get in a Laravel application.
- Do I need to install illuminate/exception in a Laravel application?
- No. laravel/framework already provides and replaces the illuminate/* components, so requiring illuminate/exception directly adds no capability and can introduce Composer constraint ambiguity. Use composer why illuminate/exception to confirm how it is already present. Remove any direct requirement if you are on full Laravel.
- How do I install illuminate/exception?
- Run composer require illuminate/exception only when you are genuinely assembling standalone Illuminate components. Pin the package major to the same Laravel major as the rest of your stack, for example 11.x alongside other Illuminate 11.x packages. If laravel/framework is installed, skip this step entirely.
- Which Laravel and PHP versions does illuminate/exception support?
- Version support mirrors laravel/framework exactly, since this is a read-only subtree split of that repository. Tags are mirrors of framework releases rather than an independent compatibility matrix, so check the framework's support policy for your major. Matching the PHP constraint of the corresponding Laravel release is the safe approach.
- Can I use illuminate/exception outside of Laravel?
- It is technically possible when assembling individual Illuminate components, but you must own the wiring of the handler, reporting, rendering, and container integration. The package is a framework component, not a general-purpose exception library, and it is not independently documented as an application-level solution. Strict version alignment across all Illuminate dependencies is required to avoid contract breaks.
- How do I customize exception reporting and rendering?
- In full Laravel you typically override report and render logic in your application's exception handler or register renderable and reportable callbacks. In a standalone setup you wire these behaviours through an application-level adapter around the handler. Keep rendering and reporting behaviour covered by tests so changes stay predictable.
- How does illuminate/exception handle HTTP exceptions and status codes?
- The handler converts exceptions into HTTP responses, mapping HTTP exceptions to their intended status codes and rendering JSON or HTML depending on the request. Non-HTTP exceptions are reported and then rendered as a generic error response. Make sure production rendering never exposes internal messages or stack traces.
- Is illuminate/exception safe to use in production?
- Yes when used through Laravel as intended, since debug output is controlled by your application configuration. The main risks are exception data leakage, recursive failures inside the handler during reporting, and Composer replace confusion when both the full framework and individual components are required. Test error paths for correct status codes and sanitized messages before shipping.
- How do I test exception handling with illuminate/exception?
- Write feature tests that hit routes triggering exceptions and assert the resulting status codes, JSON shape, and sanitized messages. Laravel's helpers such as withoutExceptionHandling let you assert the raw exception when needed. Also test that reporting failures do not recurse into the handler.
- What are the alternatives to illuminate/exception and how is it maintained?
- The primary alternative is simply relying on laravel/framework, which already ships this exact handler. Outside Laravel, developers often use Symfony's ErrorHandler or Whoops instead. Maintenance happens only upstream in laravel/framework: there is no independent release cadence, issue tracker, or PR path, and fixes must flow through the framework, so you are accepting Laravel's support policy rather than a package-specific SLA.
Weaver
How can I help you explore Laravel packages today?