Laravel 5 and Lumen both provide a convenience method on the controller for validation, so you can easily do:
$this->validate($request, $rules);
and it will handle creating the validator, checking the rules, and throwing an exception. The problem is this gets caught and transformed into a 500 error - so the developer is left implementing a custom method on the controller to handle this (see #584).
Per my comment on that issue, it's a fairly easy override. In the controller you can simply use:
use Dingo\Api\Exception\ValidationHttpException;
class ApiController extends BaseController {
protected function throwValidationException(\Illuminate\Http\Request $request, $validator) {
throw new ValidationHttpException($validator->errors());
}
}
Isn't this something that should be included out-of-the-box with Dingo? I've been surprised to find out that I have to create exception handlers manually for several typical scenarios:
Illuminate\Auth\Access\AuthorizationException and throw Symfony\Component\HttpKernel\Exception\AccessDeniedHttpExceptionfindOrFail($id) I had to manually catch Illuminate\Database\Eloquent\ModelNotFoundException and throw Symfony\Component\HttpKernel\Exception\NotFoundHttpExceptionthrowValidationException method to include the validation errors in the exception.I'm not so sure on bootstrapping all the things. I know that's how _you_ would like to handle it, but what about John Doe who wants to handle it differently, and Mary Jane who also handles it differently to John and you.
I suppose there could be room for some sort of bootstrapped variant that has everything you'd need to configure already done. But I'd prefer to keep it as simple as possible. I'm honestly not impressed with what it's doing at the moment. Becoming way to convoluted.
I'm sorry to comment on a issue which has already been closed but I thought @jdforsythe had made a very good point of the missing puzzle. Laravel/Lumen throw their own exceptions cause they have owned handlers themselves, but dingo, as a not a very framework independent package has it's responsibility to wrap them up to forming a complete API layer abstraction.
A "Custom API Error Handler Support" would resolve @jasonlewis 's concern by the way.
@jasonlewis I agree with @18601673727 . If this was a very framework independent package that would be one thing. But it's not. Also your concern about how some people would want it different is resolved by @18601673727 comment anyway.
Most helpful comment
I'm sorry to comment on a issue which has already been closed but I thought @jdforsythe had made a very good point of the missing puzzle. Laravel/Lumen throw their own exceptions cause they have owned handlers themselves, but dingo, as a not a very framework independent package has it's responsibility to wrap them up to forming a complete API layer abstraction.
A "Custom API Error Handler Support" would resolve @jasonlewis 's concern by the way.