Failed validation returns default error message even though custom messages supplied
I've finally discovered why this isn't working. It's not an issue of errors in the implementing code or Laravel, but one of either: (i). writing good PHP code to handle the self-evident result, which clearly I didn't do; (ii). insufficient documentation within Laravel on how to actually use the validation error response. Take your pick.
Laravel's validation throws a Illuminate\Validation\ValidationError. Believe it or not, this actually defaults the error message to "The given data was invalid.", so when you catch an \Exception and retrieve its $e->getMessage(), this default error-message is what you (correctly) get.
What you need to do is capture the \Illuminate\Validation\ValidationError - which I should've done originally, duh! - and then use its methods to help you distill the error messages from it.
Here's the solution I've come up with:
<?php
namespace App\Http\Controllers;
use App\Location;
use Illuminate\Http\Request;
class LocationController extends Controller
{
/**
* Action method to add a location with the supplied Data
*
* @param \Illuminate\Http\Request $p_oRequest Request
*
* @return JSON
*/
public function add(Request $p_oRequest)
{
try {
$arrValid = array(
'name' => 'required|alpha_num',
'user_id' => 'required|integer',
);
$p_oRequest->validate(
$arrValid,
array(
'name.required' => 'Name is missing',
'name.alpha_num' => 'Name must be alphanumeric',
'user_id.required' => 'User Id is missing',
'user_id.integer' => 'User Id must be an integer',
)
);
} catch (\Illuminate\Validation\ValidationException $e ) {
/**
* Validation failed
* Tell the end-user why
*/
$arrError = $e->errors(); // Useful method - thank you Laravel
/**
* Compile a string of error-messages
*/
foreach ($arrValid as $key=>$value ) {
$arrImplode[] = implode( ', ', $arrError[$key] );
}
$message = implode(', ', $arrImplode);
/**
* Populate the respose array for the JSON
*/
$arrResponse = array(
'result' => 0,
'reason' => $message,
'data' => array(),
'statusCode' => $e->status,
);
} catch (\Exception $ex) {
$arrResponse = array(
'result' => 0,
'reason' => $ex->getMessage(),
'data' => array(),
'statusCode' => 404
);
} finally {
return response()->json($arrResponse);
}
}
}
So, indeed, Laravel was supplying the correct response, and did what it said on the side of the tin, but I wasn't applying it correctly. Regardless, as a help to future me and other lost PHP-mariners at Laravel-sea, I provide the solution.
In addition, thanks to Marcin for pointing out my buggy coding, which would've caused a problem even if I had implemented the above solution.
The problem is probably that Laravel's default Exception handler is not prepared to relay detailed validation info back to the user. Instead, it hides Exception details from the user, which is normally the right thing to do because it might form a security risk for other Exceptions than validation ones.
In other words; if the Exception Handler's render
function (implemented in /app/Exceptions/Handler.php
) catches your validation errors, they will be interpreted as a general application Exception and the general error message relaid to the user will always read 'The given data was invalid'.
Make sure the render
method ignores instances of \Illuminate\Validation\ValidationException
, and you should get the response you expect:
public function render($request, Exception $exception) {
if (! $exception instanceof \Illuminate\Validation\ValidationException)) {
// ... render code for other Exceptions here
}
}
Another way to make the Exception Handler relay ValidationException details with the response would be to do something like this in the render
method:
if ($exception instanceof ValidationException && $request->expectsJson()) {
return response()->json(['message' => 'The given data was invalid.', 'errors' => $exception->validator->getMessageBag()], 422);
}
Background
Laravel is basically (ab)using Exceptions here. Normally an Exception indicates a (runtime) problem in the code, but Laravel uses them as a mechanism to facilitate request validation and supply feedback to the user. That's why, in this case, it would be incorrect to let your Exception Handler handle the Exception -- it's not an application Exception, it's info meant for the user.
The code in the answer supplied by OP works, because he catches the ValidationException himself, preventing it to be caught by the application's Exception Handler. There is no scenario in which I think that would be wanted as it's a clear mix of concerns and makes for horribly long and unreadable code. Simply ignoring ValidationExceptions or treating them differently in the Exception Handler like I showed above should do the trick just fine.
I've only just seen this but all you need to do is move the validate call before the try/catch
$p_oRequest->validate(
[
'name' => 'required|alpha_num',
'user_id' => 'required|integer',
],
[
'name.required' => 'Name is required',
'name.string' => 'Name must be alphanumeric',
'user_id.required' => 'Curator User Id is required',
'user_id.required' => 'Curator User Id must be an integer',
]
);
try {
...
} catch(\Exception $e) {
return back()->withErrors($e->getMessage())->withInput();
}
Because Laravel catches the validation exception automatically and returns you back with old input and an array of errors which you can output like
@if ($errors->any())
<div class="alert alert-danger">
<ul>
@foreach ($errors->all() as $error)
<li>{{ $error }}</li>
@endforeach
</ul>
</div>
@endif