Heimdal is a Laravel exception handler build specifically for APIs.
When building APIs there are specific formatting do's and dont's on how to send errors back to the user. Frameworks like Laravel are not build specifically for API builders. This small library just bridges that gap. For instance, specifications like JSON API have guidelines for how errors should be formatted.
composer require optimus/heimdal ~1.0Add the service provider to config/app.php
// other providers...
Optimus\Heimdal\Provider\LaravelServiceProvider::class,
Publish the configuration.
php artisan vendor:publish --provider="Optimus\Heimdal\Provider\LaravelServiceProvider"
Add the exception handler to bootstrap/app.php
$app->singleton(
Illuminate\Contracts\Debug\ExceptionHandler::class,
Optimus\Heimdal\ExceptionHandler::class
);
Imagine you have a piece of code that throws an InvalidArgumentException. This is a server error (500). It will parse through the flow
described below.
1. Exception is thrown
2. The Exception is parsed through reports. A reporter is a class that reports the Exception. Log it in logs, send to external trackers like Sentry, Bugsnag etc.
3. The Exception is parsed through an appropriate formatter that formats the response in accordance to the error type.
4. The response is sent to the user.
Yes, pretty much. However, if you want to report to something like Sentry you usually do this through something like Monolog. The problem with Monolog is that it is difficult to pick up the response of the reporters. For instance, Sentry reports back a unique ID for every reported exception which is extremely useful to give to the user, so they can give it to customer support. Heimdal supports this out-of-the-box by giving the response of all reporters to the formatter classes. This makes it trivial for formatters to use the response of the reporters in their final response to the user.
Second, Heimdal comes with sensible defaults as how different error types should be reported to the user. And makes it trivial to implement alternative responses for specific exception types.
Heimdal has two things that should be configured: formatters and reporters.
You should determine where your exceptions should be reported to. Heimdal still calls the base report function in Laravel, so your
exceptions will still be logged as normal. However, adding external reporting is easy. Heimdal comes with Sentry integration out of the box.
To send exceptions to Sentry simply add this entry to the reporters section in config/optimus.heimdal.php
'sentry' => [
'class' => \Optimus\Heimdal\Reporters\SentryReporter::class,
'config' => [
'dsn' => '',
// For extra options see https://docs.sentry.io/clients/php/config/
// php version and environment are automatically added.
'sentry_options' => []
]
]Adding a custom reporter, for instance Bugsnag, is as simple as writing a small reporter class like this
<?php
namespace My\Namespace\Exceptions\Reporters;
use Optimus\Heimdal\Reporters\ReporterInterface;
class BugsnagReporter implements ReporterInterface
{
public function __construct(array $config)
{
// initialize with config
}
public function report(Exception $e)
{
// report to bugsnag
}
}And then add it to config/optimus.heimdal.php
'bugsnag' => [
'class' => \My\Namespace\Exceptions\Reporters\BugsnagReporter::class,
'config' => [
// config.
]
]Heimdal already comes with sensible formatters out of the box. In config/optimus.heimdal.php is a section where
the formatter priority is defined.
'formatters' => [
SymfonyException\UnprocessableEntityHttpException::class => Formatters\UnprocessableEntityHttpExceptionFormatter::class,
SymfonyException\HttpException::class => Formatters\HttpExceptionFormatter::class,
Exception::class => Formatters\ExceptionFormatter::class,
],The higher the entry, the higher the priority. In this example, a UnprocessableEntityHttpException will be formatted used the
UnprocessableEntityHttpExceptionFormatter because it is the first entry. However, an NotFoundHttpException will not match
UnprocessableEntityHttpException but will match HttpException (since it is a child class hereof) and will therefore
be formatted using the HttpExceptionFormatter.
You can write custom formatters easily:
<?php
namespace My\Namespace\Exceptions\Formatters;
use Exception;
use Illuminate\Http\JsonResponse;
use Optimus\Heimdal\Formatters\BaseFormatter;
class NotFoundHttpExceptionFormatter extends BaseFormatter
{
public function format(JsonResponse $response, Exception $e, array $reporterResponses)
{
$response->setStatusCode(404);
$data = $response->getData(true);
if ($this->debug) {
$data = array_merge($data, [
'code' => $e->getCode(),
'message' => $e->getMessage(),
'exception' => (string) $e,
'line' => $e->getLine(),
'file' => $e->getFile()
]);
} else {
$data['message'] = [
'message' => 'The resource was not found.',
'log_id' => $reporterResponses['sentry']['sentry_id']
]
}
$response->setData($data);
}
}Notice how easily we used $reporterResponses to attach the ID of the Sentry log to the JSON response.
Now we simply add it to config/optimus.heimdal.php
'formatters' => [
SymfonyException\UnprocessableEntityHttpException::class => Formatters\UnprocessableEntityHttpExceptionFormatter::class,
SymfonyException\NotFoundHttpException::class => My\Namespace\Exceptions\Formatters\NotFoundHttpExceptionFormatter::class,
SymfonyException\HttpException::class => Formatters\HttpExceptionFormatter::class,
Exception::class => Formatters\ExceptionFormatter::class,
],Now all NotFoundHttpExceptions will be formatted using our custom formatter.
To send Exceptions to Sentry add the following reporter configuration in config/optimus.heimdal.php.
'reporters' => [
'sentry' => [
'class' => \Optimus\Heimdal\Reporters\SentryReporter::class,
'config' => [
'dsn' => '',
// For extra options see https://docs.sentry.io/clients/php/config/
// php version and environment are automatically added.
'sentry_options' => []
]
]
]
Sometimes you want to add information at runtime, like request data, user information or similar.
For this you can add the add_context key to the config array. Below is an example of how it could be implemented.
'reporters' => [
'sentry' => [
'class' => \Optimus\Heimdal\Reporters\SentryReporter::class,
'config' => [
'dsn' => env('SENTRY_DSN'),
// For extra options see https://docs.sentry.io/clients/php/config/
// php version and environment are automatically added.
'add_context' => function (Exception $e) {
$context = [
'environment' => app()->environment(),
'release' => \Infrastructure\Version::getGitTag()
];
$user = \Auth::User();
if ($user) {
$context['user'] = [
'id' => $user->id,
'email' => $user->email,
];
} else {
$context['user'] = [];
}
// When running in console request is not available
if (substr(php_sapi_name(), 0, 3) !== 'cli') {
$request = app('request');
if (!isset($context['extra'])) {
$context['extra'] = [];
}
$context['extra']['request_data'] = json_encode($request->all());
$context['user']['ip_address'] = \Request::getClientIp();
}
return $context;
}
]
]
]
Thanks to Nikolaj Løvenhardt Petersen for adding support
Install Bugsnag using the Laravel installation guide
To send Exceptions to Bugsnag add the following reporter configuration in config/optimus.heimdal.php.
'reporters' => [
'bugsnag' => [
'class' => \Optimus\Heimdal\Reporters\BugsnagReporter::class,
'config' => []
]
]
To send Exceptions to Rollbar add the following reporter configuration in config/optimus.heimdal.php.
'reporters' => [
'rollbar' => [
'class' => \Optimus\Heimdal\Reporters\RollbarReporter::class,
'config' => [
'access_token' => '',
'environment' => 'production'
]
]
]
The complete list of config options can be found in here
This package is compliant with PSR-1, PSR-2 and PSR-4. If you notice compliance oversights, please send a patch via pull request.
$ phpunitPlease see CONTRIBUTING for details.
The MIT License (MIT). Please see License File for more information.