Exception Laravel Package

Product Decisions This Supports

• Build vs. buy (and, here, "buy vs. vendor out") for error handling: hoa/exception is the kind of package that shows up in a dependency tree rather than in a design doc. The decision it actually informs is whether to standardize structured exception metadata (IDs, attributes, grouping, error-to-exception conversion) in-house on top of Laravel's handler, or inherit it from an upstream library. Given the package's state, the answer for greenfield work is "build/paved road," not "adopt."
• Legacy dependency triage and exit planning: With 0 listed dependents, a last release in August 2017, and an archived repository, this is a risk item on the technical-debt backlog, not a capability to roadmap against. The PM decision is prioritization: how high does "remove or isolate this transitive dependency" rank against feature work, and which quarter absorbs it.
• Platform/upgrade gating: PHP version and Laravel major upgrades are roadmap events. An archived 2017 library is a hard gate on those upgrades — it must be validated (or replaced) before a PHP 8.x / Laravel 10+ migration can be committed to. This directly shapes release sequencing.
• Observability and error-taxonomy decisions: Anything the package offers around exception attributes and grouping is superseded by what the business actually needs — structured logs, error budgets, alert routing, and user-facing error codes. Those requirements should drive the taxonomy, not a legacy library's API.
• Vendor/OSS risk posture: It's a concrete data point for a broader portfolio question — do we accept abandoned-but-stable transitive dependencies, or do we enforce a maintenance-recency policy (e.g., no unmaintained package in a production path without a documented owner)?

When to Consider This Package

Consider it only in narrow, largely inherited situations:

• You are already running a Hoa-based stack — Hoa\Compiler, Hoa\Ruler, Hoa\Regex, Hoa\Zformat and similar — where Hoa\Exception arrives as a transitive dependency. In that case the question is containment, not adoption: pin the version, wrap the boundaries, and avoid letting its exception types leak into your domain layer.
• You need grouped/aggregated exceptions or attribute-bearing exceptions and are constrained to a pre-Laravel-5 / PHP 5.x-era codebase where neither Laravel's Handler (with reportable/renderable) nor Symfony's ErrorHandler is available.
• You're doing archaeology — reading or porting code that uses Hoa\Exception, where understanding the original semantics matters more than shipping.

Look elsewhere, decisively, when:

• Any new Laravel application. Laravel ships App\Exceptions\Handler, report()/render() hooks, renderable/reportable closures, and typed exception classes. Adding a second exception base class creates two parallel error pipelines and splits your Sentry/Flare integration.
• You need maintenance guarantees. Archived, no releases since 2017, no maintainer response path, and effectively no dependent ecosystem on this registry. There will be no PHP 8 compatibility fixes, no security patches, and no CVE triage.
• You need modern error infrastructure — Flare/Ignition, Sentry, Monolog context processors, OpenTelemetry. These integrate with PSR-3 and framework handlers; a bespoke exception hierarchy is friction, not leverage.
• Compliance or audit contexts where an unmaintained dependency in a production path is a finding.

How to Pitch It (Stakeholders)

To executives — one line: This is an abandoned 2017 PHP library that we would not choose today; the recommendation is not to adopt it, and if it's already in the tree, to scope its removal as low-effort technical debt rather than treat it as a strategic component.

The substance: hoa/exception provides structured exceptions — IDs, attributes, exception grouping, and PHP-error-to-exception conversion. That's a reasonable idea, but the package is archived, has had no release since August 2017, and has no meaningful dependent community. Its functionality is already covered, better integrated, by Laravel's built-in exception handler plus our error-tracking vendor. Adopting it would introduce a second, parallel error pipeline, complicate framework and PHP upgrades, and add a dependency with no upstream support.

To engineering — the asks: (1) Confirm whether the package appears anywhere in composer.lock as a transitive dependency and, if so, which path pulls it in. (2) If present, wrap or isolate it behind our own exception boundary so it can be swapped without touching domain code. (3) Add a maintenance-recency rule to dependency review so archived packages require an explicit named owner and a removal plan before approval.

Framing: Low opportunity, high clarity. The cheap decision — don't adopt — is right, and the residual work is a small, well-bounded cleanup item rather than a roadmap risk.