- What does phisys/exceptions-bundle actually do?
- It is a Symfony bundle that wires the dosfarma/exceptions library into a Symfony application. Its purpose is centralized exception handling: exceptions are rendered, logged, and converted into consistent HTTP or API error responses instead of being handled ad hoc in each controller. The result is readable, uniform error output across environments with minimal configuration. It is a Symfony package, not a Laravel package.
- Can I use phisys/exceptions-bundle in a Laravel application?
- Not directly. The package is published as a Symfony bundle and its integration points are Symfony's kernel and bundle registration, which Laravel does not provide. There is no Laravel service provider or Laravel-specific exception renderer in this repository. Laravel developers can still study it for patterns and pair an equivalent Laravel exception handler with a similar rendering and logging layer, but installing it as-is into a Laravel app is not supported.
- How do I install phisys/exceptions-bundle with Composer?
- Install it with Composer using the package name phisys/exceptions-bundle from the phisys vendor namespace. Because the repository README is sparse, confirm the exact version constraint and any required dosfarma/exceptions version by checking the package's composer.json before committing to a constraint. Run the install in a Symfony project where bundle registration is available. Avoid pinning to a dev branch in production unless you have reviewed the code.
- Which PHP and Symfony versions does this bundle support?
- The repository description does not state an explicit support matrix, so the authoritative answer is in the composer.json require and require-dev sections. Check those constraints before upgrading PHP or Symfony, particularly around major Symfony releases where bundle and event APIs change. If the constraints are loose or absent, test on your target Symfony version in a staging branch first.
- How do I register the bundle in a Symfony application?
- Bundle registration is standard Symfony practice: add the bundle class to config/bundles.php for the environments where you want it active. Older Symfony skeletons used AppKernel registerBundles instead, so use whichever mechanism your application version provides. After registering, clear the cache and verify that exception rendering changes as expected. Consult the bundle source for the exact class name and any required configuration keys, since the README does not enumerate them.
- How does it turn exceptions into HTTP and API error responses?
- The bundle hooks into Symfony's exception handling flow and delegates the actual exception-to-response mapping to the dosfarma/exceptions library. That means an exception is normalized into a structured error payload, logged, and returned with an appropriate status code rather than a raw stack trace. The exact response shape depends on the library's formatters and your configuration, so inspect the vendor code or run a test request to see the concrete output. Always verify behavior in the dev and prod environments separately.
- Can I customize the error response format or status codes?
- Customization is handled through the underlying dosfarma/exceptions abstractions rather than a large bundle-specific configuration surface. Typical approaches are mapping exception types to status codes and swapping in a custom formatter or renderer. Because the README does not document configuration keys, read the bundle's extension class and the library interfaces before overriding anything. Write a small functional test for each customized exception type so future upgrades do not silently change your API contract.
- Will it leak stack traces or sensitive data in production?
- Centralized handling generally improves safety because rendering and logging are decided in one place instead of per controller. However, the bundle only gives you the mechanism, so you must confirm that debug output is gated on the environment and that internal exception messages are not exposed to API clients. Review your formatter configuration and run a deliberate failure in the prod environment to check the actual response body. Also confirm that logs capture the full detail while responses stay generic.
- How should I test exception handling with this bundle?
- Use Symfony's functional testing tools to issue requests that trigger each mapped exception and assert the status code and response body. KernelTestCase or WebTestCase with a test client is usually enough, and it validates both the bundle wiring and your configuration. Add unit tests around any custom formatter or mapping you introduce. Because documentation is thin, tests double as the specification for how your application handles errors.
- Is phisys/exceptions-bundle actively maintained, and what are the alternatives?
- The repository has a minimal README and no documented roadmap in the provided context, so check the commit history, tags, and open issues on GitHub before adopting it. If activity is low, treat it as a small internal-style package you may need to fork or vendor. Alternatives include Symfony's built-in error handling with a custom exception listener, or a dedicated error-handling library used directly without a bundle wrapper. Laravel teams should instead look at Laravel's own exception handler and rendering callbacks.