Функция валидации которая выбрасывает исключения?

Question

[alex4answ]

Доброе утро, есть функция в которой несколько проверок-валидаций.

const myFunc = () => {
  if(..) {
    throw new Error('Exception 1');
  }
  if(..) {
    throw new Error('Exception 2');
  }
  if(..) {
    throw new Error('Exception 3');
  }
  // далее уже, наконец-то, исполнение задачи
};

Эти проверки раздувают функцию, хочется их выделить в отдельную функцию-валидатор, но правильно ли это ?

Просто вызов этой функции будет не совсем информативный, тк она ничего не возвращает:

const myFunc = () => {
  checkCanDoSomething(); // не очень информативно, просто вызов какой-то функции проверки, ничего не возвращает
  // выполнение основной задачи
};

Выглядит странно, ранее очень редко встречал такие конструкции, обычно валидаторы что-то возвращают, либо выбросить исключение.

Как это правильно реализовать?
Вопрос скорее философский, бытовой, простой, я понимаю, но хочется найти этому разумное и красивое решение, чтобы функция была читаема

Answer 1

[Robur]

Выглядит странно, ранее очень редко встречал такие конструкции,

вполне себе нормально, assertSomething()
даже в ноде в стандартной либе есть https://nodejs.org/api/assert.html#assert_assert_o...

ваш if (cond) throw 'aaa' превращается в assert(cond, 'aaa'). Наглядно, понятно, в одну строчку. Ну или еще как вам будет удобнее.

Comments

[alex4answ]

Robur , как понял, assert скорее для разработки и в продакшн билд попасть не должен, он только для разработчика, на этапе разработки, верно?

[Robur]

alex4answ, чаще всего применяется именно так, особенно в тестах, но ничего не мешает использовать этот же подход в продакшен коде, если у вас обработка ошибок построена на исключениях.
Кидать исключения - это нормально, особенно для библиотек. Например apollo делает именно так. https://www.apollographql.com/docs/apollo-server/d...

Опять же не всегда это хорошо подходит, например в случае валидации данных лучше провалидировать все сразу и собрать ошибки, как вам тут писали. Но как по мне, дружелюбную к пользователю валидацию лучше делать на UI, а на стороне сервера чаще всего можно и на первой ошибке возвращать.

конкретно с модулем Assert в ноде есть такое неудобство что он будет кидать AssertionError, а принято кидать исключения разного типа чтобы можно было поймать нужную ошибку. В других языках есть поддержка этого в самом языке, то есть конкретный catch будет работать например на AuthorizationError, и не будет на другие, в js такого нет, но практика разных типов исключений тоже широко используется.

assert я привел как пример использования этого подхода. Можно писать свои функции, как вы привели в примере. Главное называть понятно, canDoSomething обычно предполагает возврат true/false. А assertSomething - более стандартное название для функции которая гарантирует что для дальнейшего кода какое-то условие будет выполнено. можно назвать ensureSomething или еще как-то подходящим образом.

[alex4answ]

Robur, Спасибо за развернутый ответ, мои вопросы отпали, понял, спасибо еще раз)

Answer 2

[Alex]

https://refactoring.guru/ru/design-patterns/chain-...

Comments

[alex4answ]

Не совсем подходит, тк цепь обязанностей подразумевает цепочку объектов, у меня нет ни того, ни другого.
Но направление понял, спасибо

[Alex]

alex4answ, Я имел ввиду скорее цепочку валидаторов

Answer 3

[Дмитрий Беляев]

Возвращайте Result, Ok при успешной валидации или Err с ошибкой при неудачной, а после соединяете все ошибки и выводите пользователю информацию
При throw приложение падает, Вы конечно можете поймать throw через try-catch, но он приведет Вас к полному хаосу в Вашем коде и нестабильному приложению. А кроме того, нет возможности обработать все валидации за раз, если первая упадет, об остальных юзер узнает только когда исправит данные, как думаете, на какой раз он пошлет Ваше приложение?

Comments

[alex4answ]

Дмитрий Беляев, Это библиотека, try-catch уже ответственность клиентского кода, и отлов ошибок в едином месте