When working in a development environment, Acorn automatically registers an exception handler configured to handle logging as well as the rendering of thrown exceptions. This can be especially useful when diagnosing errors thrown by Blade views.
debug option in your
config/app.php is solely responsible for whether or not an exception is handled by Acorn. By default, this option is set to be enabled when
WP_DEBUG && WP_DEBUG_DISPLAY are enabled in your WordPress config.
During local development, it is highly advised to ensure that
WP_DEBUG is enabled to properly render exceptions thrown by Blade views and other errors further down the stack.
The exception handler
By default, Acorn utilizes the Symfony exception handler. This provides an easier to read stack trace on the errors thrown in your application. While this generic error screen is useful, we recommend using Ignition during development.
If you're familiar with Laravel, you may have heard of Ignition. Ignition provides a beautiful and helpful error page for your application.
Not only does it provide useful hints pertaining to your error, it also allows you to publicly share your error using Flare. This can be very useful when it comes to submitting bug reports or requesting help on Roots Discourse.
To use Ignition, simply require it alongside Acorn as a dev-dependency, and then clear the services and packages files:
composer require spatie/laravel-ignition --dev wp acorn optimize:clear
Exception reporting can be used to log exceptions to storage or send them to an external service such as Sentry. By default, exceptions will be logged to disk located in the
Check out the documentation on logging to learn more about log implementation.
Disabling the exception handler
acorn/throw_error_exception filter can be used to disable the exception handler:
Help us continue to build and maintain our open source projects. We’re a small team of independent developers and every little bit helps.Sponsor Roots on GitHub