@websiteserf

Надо ли бросать исключение при приеме ошибочных (невалидных) данных?

Нужно ли бросать исключение, в случаях, когда данные не прошли валидацию? Или достаточно просто занести код и сообщение ошибки в массив errors и при выводе работать с ним?

UPD. Чтобы было яснее: Я хочу использовать исключения лишь для логгирования трассировки в файл. Полезна ли информация с Исключений при валидации во время дебагга?

UPD2. Разобрался. Рассуждал по след. логике:
Работа с ошибочными данными может вызвать ошибку непосредственно при их обработке. Например попытка наложить watermark на полученный файл вызовет ошибку, если был получен файл другого типа (**.exe, .*psd и т.д)
  • Вопрос задан
  • 350 просмотров
Решения вопроса 2
muhammad_97
@muhammad_97
PHP-разработчик
Да, нужно, в большинстве случаев. Можно создать класс ValidationException, который принимает в конструкторе массив сообщений с ошибками и унаследовать его от класса Exception:

class ValidationException extends Exception
{
    /**
     * Validation error messages.
     * 
     * @var array
     */
    protected $errors = [];

    /**
     * Constructor.
     * 
     * @param array $errors
     */
    public function __construct($errors)
    {
        $this -> errors = $errors;
    }

    /* геттер для свойства $errors */
}
Ответ написан
index0h
@index0h
PHP, Golang. https://github.com/index0h
Нужно ли бросать исключение, в случаях, когда данные не прошли валидацию?

Если это валидатор - достаточно вернуть ErrorResponse объект с ошибкой.
Если это вызов метода с не правильным данными - бросайте исключение.

Или достаточно просто занести код и сообщение ошибки в массив errors и при выводе работать с ним?

Не стоит, возвращайте сразу ErrorResponse.

Полезна ли информация с Исключений при валидации во время дебагга?
Да, так вы получаете stacktrace, помимо сообщения об ошибке.

Работа с ошибочными данными может вызвать ошибку непосредственно при их обработке.

Лучше не используйте ошибки, с ними не удобно работать, вместо этого исключения.

Вот вам пример, Assert::assert - это штука из либы ko-ko-ko/assert
public function loginAction(Request $request) : Response
{
    try {
        $userName = $request->request->get('userName');
        $password = $request->request->get('password');

        Assert::assert($userName, 'userName')->match('/^[\a-z\d]{3,32}$/i');
        Assert::assert($password, 'password')->lengthBetween(6, 32);
    } catch (\Throwable $exception) {
        return new Response($exception->getMessage(), Response::HTTP_BAD_REQUEST);
    }

    try {
        // Your business logic here
        
        return Response();
    } catch (\Throwable $exception) {
        $this->get('logger')->error($exception->getMessage(), ['exception' => $exception]);
        return new Response('Could not login', Response::HTTP_INTERNAL_SERVER_ERROR);
    }
}
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@r_zaycev
Исключение бросается в исключительной ситуации, которую нельзя предотвратить. Валидация принятых данных это явно не тот случай.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы