- Is exs/error-bundle compatible with Laravel?
- No. exs/error-bundle is a Symfony 2.x bundle, not a Laravel package, and it has no Laravel service provider, facade, config publish, migration, or Eloquent model. Direct Composer installation in a Laravel app has low viability because it pulls Symfony 2-era components that conflict with Laravel's modern symfony/* constraints and PHP 8.x. Treat it as a pattern donor rather than a dependency.
- Can I install exs/error-bundle in a Laravel application?
- It is not recommended. Composer resolution will likely pull Symfony 2-era components that conflict with Laravel's modern symfony/* constraints and PHP 8.x. The practical path is to reimplement the behavior natively in Laravel or use managed error tracking instead.
- How does exs/error-bundle log 4xx and 5xx errors?
- It registers a Symfony container service that listens for HTTP 4xx and 5xx exceptions and persists them via Doctrine. Each record captures useful debugging details for the error. The bundle is designed to be paired with a cron-based monitor so the dev team can spot error spikes and alert quickly.
- What Laravel versions does exs/error-bundle support?
- None. There is no Laravel auto-discovery, PSR-3 logger binding, Laravel queue integration, or event integration. The only relationship is conceptual: Symfony's kernel.exception listener roughly maps to Laravel's App\Exceptions\Handler::report(), the Doctrine entity maps to an Eloquent model, and bundle YAML/XML config maps to a config/error-bundle.php file.
- How do I install exs/error-bundle in a Symfony 2 project?
- Run composer require 'exs/error-bundle:1.0', then register EXS\ErrorBundle\EXSErrorBundle in app/AppKernel.php, add the bundle routing in app/config/routing.yml, add the ORM mapping in app/config/config.yml, and set the deprecated_errors_logging parameter. Clear the cache and run doctrine:schema:update --force. You can test it by throwing 500 and 400 series errors and confirming they are logged with debugging details.
- Does exs/error-bundle work with PHP 8?
- It is unlikely to work without a fork. The last release was 2015-09-30, Symfony 2.x is long EOL, and the code targets PHP 5.x and 7.0-era idioms. Static analysis under PHP 8.1+ will likely surface deprecations and type issues, which reinforces the fork-or-reimplement decision.
- What are alternatives to exs/error-bundle for Laravel error tracking?
- Managed error tracking services such as Sentry, Bugsnag, Flare, and CloudWatch likely cover both durable error audit trails and on-call alerting with less ownership. You would instrument Laravel's exception handler to report to the chosen service. Make a build-vs-buy decision with the cost of ownership stated explicitly before writing schema or handler code.
- How do I implement EXS ErrorBundle-style error logging in Laravel?
- Hook into App\Exceptions\Handler::report() and create an errors table keyed by a fingerprint hash of the exception class, normalized message, and top frame, with first_seen, last_seen, count, level, redacted context, and a truncated trace. Use a queued reporting job to decouple the request path and a scheduled errors:monitor console command for threshold alerting. Define redaction and retention policy before production traffic, and roll out behind a feature flag on one service before expanding.
- Is exs/error-bundle actively maintained?
- No. The last release was 2015-09-30, and the repository shows 1 star, 0 dependents, and no visible test suite or CI. That means no community validation, no security response path, and no upgrade pressure. Symfony 2.x is long EOL, so the code should not be treated as a supported production dependency.
- What production concerns come with database-backed error logging like exs/error-bundle?
- Database-backed exception logging creates write amplification during incident storms, precisely when the database is least able to absorb extra writes. Exception payloads commonly contain PII, tokens, and connection strings, and the README describes no redaction, sampling, dedupe, or retention. There is also no described backpressure, retry policy, or self-failure guard. Before production use, define retention, PII redaction, access-control obligations, expected error volume, and database write headroom during an outage.