Catchable Bundle Laravel Package

Product Decisions This Supports

• Defining a public API error contract. The package's real capability is per-controller, attribute-driven mapping of domain exceptions to structured HTTP responses, plus fallback handling for unmatched exceptions. That is a direct input to a decision we will face regardless of vendor: do our API errors have a documented, stable shape (status code + machine-readable code + message + correlation ID), or does each endpoint improvise? Read the package as a worked example of the "errors declared next to the code that raises them" pattern before we codify our own contract.
• Build vs. buy on error-handling boilerplate. The honest comparison is not this package versus Sentry — it is this package versus roughly 100 lines in Laravel's Illuminate\Foundation\Exceptions\Handler (a renderable() closure per exception type, or typed exceptions implementing render()/Responsable). Laravel already ships the mechanism. The build decision is therefore cheap on both sides, and the tiebreaker is governance, not features.
• Roadmap input for API consistency / partner readiness. If we are preparing a public or partner-facing API, a consistent error envelope is a launch blocker, not a nice-to-have. This package scopes the smallest version of that work: exception → status mapping, a default fallback, no per-endpoint try/catch. Use it to size the increment (typically days), not to justify a dependency.
• Developer-experience decisions. It supports the case for removing repetitive try/catch from controllers and separating domain exceptions from transport concerns. That refactor is worth doing whether or not any package is adopted, and is the durable value here.
• Scoping correction worth flagging internally. Prior notes on this package framed it as an observability/exception-collection tool and compared it to Sentry, Flare, and Bugsnag. The description describes exception-to-response mapping, which is a different problem with a different buy decision. Confirm the actual requirement before any comparison — "we can't see what's breaking" (observability, buy) and "our error responses are inconsistent" (contract, build) lead to opposite conclusions.
• Use cases it plausibly serves: standardizing error responses across a service's endpoints, mapping a domain exception taxonomy to HTTP status codes, and giving API consumers predictable failure modes. It does not address tracing, alerting, retention, release tracking, or PII scrubbing — those remain a separate buy.

When to Consider This Package

Consider it when:

• You own a Symfony application — the bundle lifecycle (Kernel::registerBundles(), DI extension, service definitions) is a hard prerequisite.
• The requirement is narrow and internal: consistent error responses, less try/catch, a fallback for the unexpected.
• You are willing to vendor or fork it and assign a named owner, treating it as source you now maintain rather than a dependency you consume.
• You want a half-day reference read to pressure-test your own error-contract design before writing it.

Look elsewhere when:

• The target is Laravel. This is the decisive point. The package is a Symfony bundle; there is no configuration-only path into Laravel's service-provider and exception-handler pipeline. Adoption is a port, and after the port the Symfony scaffolding is discarded — which means you did not adopt a package, you read one.
• The NOASSERTION license is unresolved. No recognized license means no clear grant to use, modify, or redistribute. Treat as a legal stop, not an engineering tradeoff, and note that a zero-adoption repository is unlikely to clarify.
• You need it in a production path. 0 stars, 0 dependents, no issue history, no maintainer means no security response for code that runs on every request.
• Your real gap is observability. If the problem is "we can't see what's failing in production," a maintained, MIT-licensed reporter is the answer and this package is a category error.
• You need a single, organization-wide error contract. Per-controller mapping fragments the contract across endpoints. At scale, a central handler plus a documented exception taxonomy is the better shape — and it is what this package would be replaced by anyway.
• Composer compatibility is unverified. Legacy bundles typically pin older Symfony components that conflict with the Symfony 6/7 components Laravel 10/11 pulls in. Dry-run composer require before spending evaluation time.

Adoption gate: require a license determination, a Laravel-versus-Symfony confirmation, and a named internal owner with a forking plan before it enters any production path. Absent all three, close the item.

How to Pitch It (Stakeholders)

For executives: We have a decision to make about API error consistency, and a small open-source Symfony bundle surfaced as a possible shortcut. It is not usable as a dependency: it targets a different framework than our Laravel stack, it has no users or maintainers, and its license is unresolved — which is a legal blocker, not a technical preference. The useful outcome is that it shows how cheap the underlying pattern is. Recommendation: fund no integration work; spend a day documenting the rejection and route the requirement to either a maintained error reporter (if the gap is visibility) or a small owner-built exception handler (if the gap is consistent error responses). Either path is days, not a project.

For engineering: Read it, don't require it. The pattern is worth stealing conceptually: map a domain exception to a status code and a stable payload once, at the boundary, instead of try/catch in every controller. In Laravel that is a reportable()/renderable() hook on the exception handler, or typed exceptions implementing render() — fully owned, testable, and framework-native. If we do anything, we write it ourselves in under a sprint and document the contract. Watch the failure modes while we do: the handler must not recurse on its own errors, must degrade to the native handler rather than swallow silently, and must not leak request bodies or traces into responses. If instead the requirement turns out to be "we need to see what's breaking in production," this package is the wrong tool entirely — that is a maintained SDK, and the build-vs-buy math flips in favor of buying.