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
Introducing Flare’s next big feature: performance monitoring
Flare's new Performance Monitoring feature is now live, giving you complete visibility into your Laravel app's HTTP routes, queued jobs, Artisan commands, and database queries.
Freek
Lessons from the deep end
20 months ago, we started building Performance Monitoring as Flare’s next big feature, never expecting Laravel’s rapid commercial growth to put us in direct competition with their own tools. This is our honest take on those 20 months went, how we’re adapting to this new reality, and where we’re heading next while staying true to who we are. A dive into the deep end, without knowing how far down it goes.
Alex
Subscribe to Backtrace, our quarterly Flare newsletter
No spam, just news & product updates