Obereg Bundle Laravel Package

Getting Started

OberegBundle is a Symfony bundle (mekras/obereg-bundle), not a Laravel package. There is no service provider, no config/obereg.php, no Facade, and no package auto-discovery. It wires itself into Symfony's kernel.exception event via the bundle registration in AppKernel, so there is no path to installing it into a Laravel app with composer require and having it "just work." The last tagged release is from 2015-05-07 and it targets the Symfony 2.x API and PHP 5.x era.

Where to look first, if you are evaluating it:

1. composer.json — check the symfony/symfony and php constraints. They will confirm it cannot resolve against a modern Symfony, let alone Laravel.
2. The exception listener registered on kernel.exception — this is the whole product: intercept an exception, decide what to render, set a Response, and stop propagation.
3. The bundle's semantic configuration (the Configuration class / extension) — this shows how exception classes are mapped to status codes and templates.

First use case it was built for (on Symfony): replace the default Twig "Oops" page with per-exception-class error pages, and return JSON for API-style requests instead of HTML. In Laravel, the day-to-day equivalent is App\Exceptions\Handler (Laravel ≤10) or bootstrap/app.php → ->withExceptions(...) (Laravel 11+). Start there; borrow the concept, not the code.

Implementation Patterns

Since you cannot run the bundle in Laravel, the practical pattern is to reimplement its idea — centralized, type-aware error rendering — in Laravel's native exception pipeline.

Exception-class → response mapping. In withExceptions() (Laravel 11+) or Handler::register(), bind specific exception types to status codes and payloads:

->withExceptions(function (Exceptions $exceptions) {
    $exceptions->render(function (DomainException $e, Request $request) {
        return $request->expectsJson()
            ? response()->json(['error' => $e->getMessage()], 422)
            : response()->view('errors.domain', ['e' => $e], 422);
    });
})

This mirrors what Obereg's listener did with its exception→template configuration.

Content negotiation. Obereg decided between HTML and JSON output. Laravel's $request->expectsJson() (or $request->is('api/*')) is the equivalent and is more reliable than sniffing Accept by hand.

Keep controllers thin. The whole point of an error-handling bundle is that controllers do not try/catch for presentation. Preserve that discipline: let exceptions bubble, render centrally.

Reporting vs rendering. Obereg-style bundles usually conflate logging and rendering; Laravel separates them. Use report()/$exceptions->report(...) for logging and render() for output. Do not log inside a renderer.

If you genuinely need to read the Symfony source (e.g., you are porting an app off Symfony 2): the listener pattern is event->setResponse($response) to short-circuit, and listener priority determines which handler wins. Map that mental model onto Laravel's renderable ordering.

Gotchas and Tips

• Abandoned and stale. 0 stars, 0 dependents, last release 2015. No security patches, PHP 5-era code, Symfony 2 API. Do not introduce it into any maintained codebase, Laravel or otherwise.
• No Laravel bridge exists and none will. There is no OberegServiceProvider, no extra.laravel block, no auto-discovery. Any integration would be a from-scratch port, at which point you have written more code than withExceptions() needs.
• Error pages are a security surface. The single most common mistake in these bundles is rendering exception messages, arguments, or traces in production templates. In Laravel, gate on config('app.debug') and never render $e->getTrace() outside local.
• Symfony bundle registration vs Laravel discovery trips people up when reading docs: AppKernel::registerBundles() has no Laravel analogue. Do not look for a config/app.php providers entry; it isn't there.
• Debugging the original: in Symfony, kernel.debug and the profiler's exception panel are where you inspect it; listener priority bugs manifest as "my handler never fires." The Laravel equivalent for "my renderer never fires" is checking that a more specific renderable (or a Responsable/render() method on the exception itself) is not winning.
• The one thing worth stealing is the idea of a declarative exception→status→template table. If your app has more than a handful of domain exceptions, a small config map plus a single renderer is cleaner than a pile of renderable closures — but implement it yourself; do not resurrect the bundle to get it.