Console Exception Bundle Laravel Package

Product Decisions This Supports

• Observability gap for CLI workloads. Symfony's console runtime prints uncaught exceptions to stderr and exits non-zero; nothing routes them through your application's PSR-3 logger. If cron jobs, queue workers, or import/export commands are part of your surface area, this bundle's core idea — an event subscriber on console.exception that logs through the app logger — closes a real gap in incident detection.
• Roadmap framing: "Reliability for non-HTTP surfaces." Most teams instrument web requests (Sentry, APM, access logs) and leave batch/CLI paths dark. This package is a citable reference when arguing that the observability initiative should include CLI, not just HTTP.
• Build vs. buy → build. It is archived, last released June 2016, has one star and zero dependents. Do not treat it as a dependency decision; treat it as a ~30-line design pattern. Modern equivalents are a kernel.exception-style console event subscriber plus Monolog's ConsoleHandler, or simply the Sentry/Monolog Symfony SDKs, which already capture console exceptions.
• Use cases it validates: scheduled-job failure alerting, exit-code semantics (distinguish "command failed" from "command failed and someone was paged"), and post-hoc debugging of nightly jobs whose stderr is discarded by the scheduler.
• Decision it should not drive: it should not appear in a dependency manifest, an SBOM, or a security review queue. Adopting abandoned code to solve a solved problem is a net-negative roadmap item.

When to Consider This Package

Consider it only when all of the following hold:

• You maintain a legacy Symfony 2.x/3.x application that is frozen (no framework upgrade planned) and has no exception logging on console commands.
• You need a stopgap inside a single maintenance window and cannot allocate time for a custom subscriber.
• You have accepted that you will vendor/fork the code and own it — the upstream is archived and will never receive a patch.

Look elsewhere — i.e., do not adopt — when any of these are true (which is the default case):

• You are on Symfony 4.4+, where console exception events, Monolog handlers, and Sentry's Symfony SDK cover this natively with maintained code.
• You need PHP 8 compatibility, security patching, or a supported dependency — none of which an archived 2016 bundle provides.
• Your real requirement is alerting, not logging; a logger bundle does not page anyone. Pair logging with a monitored sink (Sentry, Opsgenie, PagerDuty) or it is just nicer stderr.
• The effort to write the equivalent subscriber is under a day, which it is.

How to Pitch It (Stakeholders)

To executives: We have a blind spot — when a scheduled job or console command fails, the error goes to a terminal nobody is watching. We found a package that addresses exactly this, but it is archived, unmaintained since 2016, and effectively unused (1 star, 0 dependents). Recommendation: do not add it as a dependency. Instead, spend roughly one engineering day implementing the same behavior in-house against our current Symfony version, and route output into the logging and alerting we already pay for. Outcome: CLI failures become visible and alertable this sprint, with no new supply-chain or maintenance risk.

To engineering: The pattern is a console exception event subscriber that catches throwables from commands, logs them through the existing PSR-3 logger (so they inherit our Monolog handlers, context processors, and Sentry transport), and lets the non-zero exit code propagate so schedulers still see failure. Scope is small, testable, and framework-native; it removes the need for a third-party bundle and gives us one place to add command-level context (command name, arguments, duration).

To security/procurement: No new third-party code enters the estate. This avoids an archived dependency with no CVE response path and no PHP 8 support — a small but permanent liability we would otherwise carry for a problem we can solve internally.