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
One core, many clients: the new Flare JavaScript client architecture
We recently reshaped the Flare JavaScript client from a single browser library and a few thin framework specific packages into a small family of packages built on a shared, platform-agnostic core. This post explains why we did it, what the core package exposes, how the browser and Node SDKs are built on top of it, why the React, Vue, and Svelte packages sit one level higher, and how anyone can use the same core to write a Flare JS client for a platform we do not ship ourselves.
Dries
Logging is here!
Logging is now available for all Flare users! Send any log from your app to Flare and use our polished interface to filter and search your logs in real-time.
Jimi
Subscribe to Backtrace, our quarterly Flare newsletter
No spam, just news & product updates