Api Exception Bundle Laravel Package

Product Decisions This Supports

• API error-contract standardization: If the roadmap includes exposing a public/partner API, RFC 7807 (application/problem+json) is the canonical way to make error payloads machine-parseable and self-documenting. This package is a ready-made implementation of that contract for Symfony applications, so it informs the "do we standardize error responses now or later?" decision.
• Build vs. buy (vs. copy): The core logic — register a kernel exception listener, map exception types to HTTP status codes, emit a problem+json body — is roughly 100–200 lines of code. The decision this package surfaces is not "buy" (it's free and unmaintained) but "vendor a reference implementation vs. write our own listener," which is really a build vs. fork call.
• Feature scoping for error-handling epics: Useful as a requirements checklist when writing acceptance criteria for an error-handling story: status-code mapping, content negotiation, type/title/detail/instance fields, no stack traces in production, correlation IDs.
• Framework-fit screening: It forces an explicit decision about whether our stack is Symfony-centric. Because this is a Symfony bundle, not a Laravel package, it is a data point against "we can drop any PHP error library into any PHP service" — supporting a decision to standardize error handling per framework rather than per language.
• Technical-debt / risk register input: Stale (last release June 2020), zero stars, zero dependents, zero score. Its presence in a dependency audit supports a "reject unmaintained third-party error handlers" policy, since error rendering is on the hot path for every failed request.

When to Consider This Package

Consider it only as a reference implementation or a short-lived stopgap when all of the following hold:

• The service is Symfony (5.x era matching a 2020 bundle), not Laravel, Slim, or plain PSR-15 middleware.
• You need RFC 7807 responses this sprint and cannot budget a day of engineering for a custom kernel.exception listener.
• The service is internal or low-traffic, so an unmaintained dependency in the error path is an acceptable, time-boxed risk.
• You have read the source and are comfortable forking it in-house; plan to vendor or fork on day one rather than depend on the upstream tag.
• You are willing to pair it with your own logging/correlation-ID layer, since a 2020 package will not cover modern observability needs.

Look elsewhere — or build — when:

• The application is Laravel: this package binds to Symfony's event dispatcher and bundle system. Laravel's equivalent is a few lines in App\Exceptions\Handler::render() plus a small problem+json serializer (e.g. crell/api-problem as the DTO layer). Do not attempt to install it in Laravel.
• The API is public, contractual, or security-sensitive: error responses leak internals if the mapping is wrong, and you need an actively maintained, reviewed component on that path.
• You need modern coverage: PHP 8.1+ attributes, Symfony 6/7, OpenAPI-generated error schemas, Retry-After/rate-limit headers, i18n of detail messages.
• Your team already has a shared HTTP kernel/middleware package — adding a second error pipeline creates conflicting handlers and unpredictable precedence.
• An actively maintained alternative exists in your ecosystem; a zero-star, five-year-dormant package should lose that comparison by default.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source library that turns application errors into a standard, machine-readable JSON error format (RFC 7807). The idea is worth adopting — it makes our APIs easier for partners to integrate with and easier for us to support — but this particular library is not something to depend on: it is a Symfony-only component, last released in 2020, with no users and no maintainer. Recommendation: adopt the RFC 7807 standard, and have engineering implement the ~150 lines ourselves (or fork this as a reference) so we own the code path that runs on every failed request. Cost: under a week. Risk avoided: an unmaintained dependency in our error handling, which is both a reliability and an information-disclosure surface.

For engineering (talking points):

• Scope check first: it's a Symfony bundle. It does not apply to our Laravel services. Treat it as a spec reference, not a dependency.
• Implementation sketch: an exception listener that maps exception class → status code, emits application/problem+json with type, title, status, detail, instance; suppresses traces outside dev; logs with a correlation ID that is echoed in instance.
• Cost of ownership is tiny, cost of dependency is not: the whole feature is a listener plus a value object. We can cover it with a handful of functional tests.
• What we gain: a stable error contract we can document in OpenAPI, per-type error URLs that double as documentation, and consistent client-side error handling.
• Verdict: Do not adopt as a dependency. Adopt the standard; write or vendor the listener; revisit in a year only if an actively maintained Symfony 7-compatible option appears.