-
Notifications
You must be signed in to change notification settings - Fork 18
Allow to configure a default type map #50
Comments
I'm not sure if it is useful (although others might think it is). There is already a way to create custom exceptions. namespace Api;
use DomainException as PhpDomainException;
use Zend\ProblemDetails\Exception\CommonProblemDetailsExceptionTrait;
use Zend\ProblemDetails\Exception\ProblemDetailsExceptionInterface;
class ResourceNotFoundException extends PhpDomainException implements ProblemDetailsExceptionInterface
{
use CommonProblemDetailsExceptionTrait;
public static function create(string $message, array $details) : self
{
$e = new self($message)
$e->status = 404;
$e->detail = $message;
$e->type = 'https://example.com/my-app/errors/resource-not-found';
$e->title = 'Resource not found';
$e->additional['transaction'] = $details;
return $e;
}
} You throw a |
Yes. In any case in which I manually throw an exception, I'm in control of everything which is going to be returned. The problem is when something I cannot control happens. For example, when a request is performed to a route which does not match any configured route. Or if for some reason, some third party exception ends up not being caught and goes up to the error handling middleware (I try to catch those and wrap them into domain exceptions which implement problem details, but something could go wrong). I would like to be able to have a consistent set of API errors, even for those cases. However, I have already implemented a workaround (not so nice, but it works), so if you really think this is not useful, I will live with it :) |
Thanks for the explanation. If you want to create a PR, that would be awesome. |
Great! I will sure do :) |
Just created the PR: #51 Monitoring the builds to make sure they pass. |
This repository has been closed and moved to mezzio/mezzio-problem-details; a new issue has been opened at mezzio/mezzio-problem-details#1. |
Currently, when the
ProblemDetailsResponseFactory::createResponse
method is called without atype
, it tries to infer it from thestatus
, generating values likehttps://httpstatus.es/404
orhttps://httpstatus.es/500
.This mainly happens when the
ProblemDetailsNotFoundHandler
is hit, or theProblemDetailsMiddleware
catches an exception not implementingProblemDetailsExceptionInterface
.If your API has a specific pattern when generating the
types
for other errors, it's a bit inconsistent that these two errors follow a different pattern.It would be nice to be able to define a config map where you set the default type to be used for "every" status code when a value for type was not provided. Something like this:
Then, by injecting this map in the
ProblemDetailsResponseFactory
, thecreateTypeFromStatus
method could be refactored to look like this:So it would continue working the same when the config map is not defined, but every user would have control over the values generated for the type.
I'm open to implement this if you think it's useful.
The text was updated successfully, but these errors were encountered: