1. Introduction
When starting a new lumen project, error and exception handling have been configured by default for you. In addition, Lumen integrates a Monolog log library that provides a wide variety of powerful log processors.
2. Configuration
Error details
Configuration file. The app_debug configuration option in Env controls the number of error details displayed by the browser.
For local development, you should set the environment variable App_debug value to True. In a production environment, the value should be set to false.
Customizing the Monolog configuration
If you want full control over the configuration of the Monolog, you can use the Configuremonologusing method, and you need to call the method in bootstrap/app.php:
$app->configuremonologusing (function ($monolog) { $monolog->pushhandler (...);}); return $app;
3. Exception Processor
All exceptions are handled by Class App\exceptions\handler, which consists of two methods: report and Render. Let's elaborate on these two methods.
3.1 Report method
The report method is used to log exceptions and send them to external services such as Bugsnag. By default, the report method simply passes the exception to the base class where the exception is recorded, and you can record the exception as you like.
For example, if you need to report different types of exceptions in different ways, you can use the PHP instanceof comparison operator:
/** * Report or Record exception * * This is a great spot to send exceptions to Sentry, Bugsnag, etc. * * @param \exception $e * @ret Urn void */public function report (Exception $e) { if ($e instanceof customexception) { // } return Parent :: report ($E);}
Ignoring exceptions by type
The $dontReport attribute of the exception handler contains an array of exception types that will not be logged, and by default the 404 error exception will not be written to the log file, and you can add additional exception types to this array, if necessary.
3.2 Render Method
The Render method is responsible for translating the given exception into the HTTP response sent to the browser, by default, the exception is passed to the base class that generated the response for you. However, you can check the exception type as you wish or return a custom response:
/** * Render exception to Http response * * @param \illuminate\http\request $request * @param \exception $e * @return \ Illuminate\http\response */public function Render ($request, Exception $e) { if ($e instanceof customexception) { C11/>return response ()->view (' Errors.custom ', [], +); } Return Parent::render ($request, $e);}
4. HTTP Exception
Some exceptions describe HTTP error codes from the server, for example, this could be a "page not found" error (404), "Authentication Failure Error" (401) or a 500 error caused by a program error, in order to generate such a response in the application, use the following method:
Abort (404);
The Abort method immediately throws an exception that will be rendered by the exception handler, and you can provide a response description like this:
Abort (403, ' unauthorized action. ');
This method can be used at any point in the request life cycle.
5. Log
The Lumen log tool is based on a powerful Monolog library, and by default, lumen is configured to generate log files for the app daily in the Storage/logs directory, and you can write log information to the log using the log façade:
User::findorfail ($id)]);} }
The logger provides seven levels of logging defined in RFC 5424: alert, critical, error, warning, notice, Info and debug.
Log::alert ($error); Log::critical ($error); Log::error ($error); Log::warning ($error); Log::notice ($error); Log::info ($error); Log::d ebug ($error);
Contextual information
The context data array is also passed to the log method. The context data will be formatted and displayed along with the log message:
Log::info (' User failed to login. ', [' id ' = ' = $user->id]);