By default, Ignition and the Flare PHP client (if you're using Flare in a non-Laravel application) will always send all the exceptions and errors to Flare.
In the cases where you don't want all exceptions being sent to Flare, you can from now on filter the exceptions sent using a callback:
// in ignition
Flare::filterExceptionsUsing(
fn(Throwable $throwable) => !$throwable instanceof AuthorizationException
);
// in the flare-php-client
$flare->filterExceptionsUsing(
fn(Throwable $throwable) => !$throwable instanceof AuthorizationException
);
When a PHP error is thrown, you can now configure which levels of errors should be sent to Flare:
// in ignition
Flare::reportErrorLevels(E_ALL & ~E_NOTICE);
// in the flare-php-client
$flare->reportErrorLevels(E_ALL & ~E_NOTICE);
In this case, Flare will send all PHP's internal errors except E_NOTICE errors.
Continue reading
Version 2 of our JavaScript client libraries
We shipped v2 of @flareapp/js, @flareapp/react, @flareapp/vue, and @flareapp/vite. The framework packages now handle error boundaries, automatic context collection, and component prop capture out of the box. The core client talks to a new, faster ingestion endpoint, and the Vite plugin got retry logic and smarter sourcemap handling.
Sébastien
Flare ❤️ Livewire
Flare has deep Livewire visibility: components nested in traces with full hierarchy, per-phase timing (mount, hydrate, render, dehydrate), aggregated component views with bidirectional links, rich error context, and a lot more. Let us show you how Flare can assist in debugging your Livewire project.
Ruben
Subscribe to Backtrace, our quarterly Flare newsletter
No spam, just news & product updates