Weave Code
Exception Toolkit Laravel Package
phphd/exception-toolkit
A PHP/Laravel exception toolkit for centralizing error handling: customize reporting, rendering, logging, and response formatting for exceptions. It helps turn thrown errors into consistent, actionable responses and cleaner application code.
Bundle to easily deal with exceptions
Frequently asked questions about Exception Toolkit
- Is phphd/exception-toolkit a Laravel package or a Symfony-first library?
- It is best treated as a framework-agnostic PHP exception toolkit with a Symfony-first dependency injection surface. Version 1.2.0 exposes PhdExceptionToolkitExtension::getContainer() and PhdExceptionToolkitExtension::configureContainer(), which follow the classic Symfony DependencyInjection Extension shape rather than Laravel's ServiceProvider shape. In a Laravel app you would normally consume the underlying exception logic directly or write a thin adapter ServiceProvider that maps its configuration into Laravel config and bindings.
- How do I install phphd/exception-toolkit with Composer?
- Install it with Composer, for example composer require phphd/exception-toolkit:^1.2, and commit the lock file so the resolved version is pinned. After installing, check the package's composer.json for its PHP and Symfony constraints before assuming it fits your runtime. Because there is no Laravel ServiceProvider in the package, you should expect to register any bindings yourself in a provider or in bootstrap/app.php.
- Which Laravel and PHP versions does phphd/exception-toolkit support?
- The available release metadata does not document explicit Laravel or Illuminate version bounds, so you need to verify the PHP constraint in composer.json yourself. Since the package does not appear to ship a Laravel ServiceProvider, practical compatibility is mostly driven by the PHP version constraint and whether the core classes are plain PHP. Test on your target Laravel version before rolling it out beyond a spike branch.
- What does PhdExceptionToolkitExtension::getContainer() do in version 1.2.0?
- It exposes the extension's container instance so consumers can resolve dependencies directly. That is effectively a service-locator seam, so it is safest to call it only at a composition root such as a service provider rather than at arbitrary call sites. Pulling dependencies out of the container deep in application code makes static analysis and test isolation harder and is a likely future deprecation point.
- What does configureContainer() accept and does it override my Laravel config?
- configureContainer() is the extension's configuration entry point and mirrors the Symfony Extension pattern of feeding configuration into a container. It has no direct Laravel analogue, so any Laravel usage requires you to map those values into config files or bindings manually. If you also configure the toolkit through framework-level config, decide explicitly which source wins, because two configuration entry points with unclear precedence cause environment-specific bugs.
- Can phphd/exception-toolkit be used standalone without Symfony DI?
- The package is described as a bundle for dealing with exceptions, and its exception classification and normalization logic is the part most likely usable on its own. Whether the core pipeline works without the Symfony extension layer is the key unknown, and it determines whether a Laravel adapter is twenty lines or a couple hundred. Inspect the source to confirm the core classes have no hard dependency on a Symfony kernel before committing to an approach.
- How do I wire phphd/exception-toolkit into Laravel's exception handler?
- Integrate it where exceptions are already centralized: App\Exceptions\Handler, the withExceptions closure in Laravel 11+, a response-formatting middleware, and a job-level failed() hook. Keep the mapping from your exception taxonomy to reports, log levels, and HTTP responses in one place so behavior stays predictable. The toolkit adds the most value when your app already has a shared error taxonomy rather than scattered try/catch blocks.
- Is upgrading phphd/exception-toolkit from 1.1.0 to 1.2.0 a breaking change?
- No breaking changes are declared, and the 1.1.0 to 1.2.0 change set is additive: a new getContainer() getter and a configureContainer() entry point. Upgrade risk from 1.1.0 is therefore low. The risk sits with newly adopting the extension API, not with the version bump itself.
- Is phphd/exception-toolkit safe to use in production?
- The package comes from a small vendor namespace with unverified release cadence, test coverage, and maintainer backing, so treat it as a dependency that needs review. Pin to ^1.2 with a committed lock file rather than floating the constraint, and wrap the integration behind your own interface so you can swap it out. Watch for security patch responsiveness and avoid exposing getContainer() as a general-purpose escape hatch in your own codebase.
- What are the alternatives to phphd/exception-toolkit for Laravel error handling?
- Most Laravel teams rely on the native exception handler plus Illuminate reporting, optionally with spatie/laravel-ignition for local debugging and Sentry or Flare for production aggregation. Symfony's ErrorHandler is the closest equivalent if you need the same behavior outside Laravel. Choose phphd/exception-toolkit mainly if you want a shared exception taxonomy and consistent response formatting across PHP and Laravel services.
Weaver
How can I help you explore Laravel packages today?