Fix a bug causing DataIntegrityExceptions to not be caught correctly and cause a second exception... whoops.

This commit is contained in:
Dane Everitt 2019-03-03 13:42:32 -08:00
parent 114afb8646
commit cf31d4276c
No known key found for this signature in database
GPG key ID: EEA66103B3D71F53
2 changed files with 23 additions and 0 deletions

View file

@ -15,6 +15,7 @@ use Illuminate\Database\Eloquent\ModelNotFoundException;
use Symfony\Component\HttpKernel\Exception\HttpException;
use Pterodactyl\Exceptions\Repository\RecordNotFoundException;
use Illuminate\Foundation\Exceptions\Handler as ExceptionHandler;
use Symfony\Component\HttpKernel\Exception\HttpExceptionInterface;
class Handler extends ExceptionHandler
{
@ -153,6 +154,26 @@ class Handler extends ExceptionHandler
$connections->rollBack(0);
}
// Because of some breaking change snuck into a Laravel update that didn't get caught
// by any of the tests, exceptions implementing the HttpExceptionInterface get marked
// as being HttpExceptions, but aren't actually implementing the HttpException abstract.
//
// This is incredibly annoying because we can't just temporarily override the handler to
// allow these (at least without taking on a high maintenance cost). Laravel 5.8 fixes this,
// so when we update (or have updated) this code can be removed.
//
// @see https://github.com/laravel/framework/pull/25975
// @todo remove this code when upgrading to Laravel 5.8
if ($exception instanceof HttpExceptionInterface && ! $exception instanceof HttpException) {
$exception = new HttpException(
$exception->getStatusCode(),
$exception->getMessage(),
$exception,
$exception->getHeaders(),
$exception->getCode()
);
}
return parent::render($request, $exception);
}