Валидация данных: другой подход

[@lair]

Проверка данных в приложении введённых пользователем или полученных другим путём в классическом понимании подразумевает использование всего лишь двух выражений в коде: TRUE и FALSE.

Что за "классическое понимание", и где вы его взяли? В .net IValidatableObject.Validate возвращает коллекцию ValidationResult, а ModelState (в ASP.net MVC) содержит коллекцию ModelError.

[@Vadem]

Так и в Java есть Jakarta Bean Validation, в котором Validator.validate() возвращает Set<ConstraintViolation>.
Автор просто решил изобрести велосипед видимо.

[@Moriline]

Не всегда эту реализацию возможно использовать в проекте. Например: в JavaSE или android. Плюс к этому там используются исключения при валидации.

[@Vadem]

Не всегда эту реализацию возможно использовать в проекте. Например: в JavaSE или android.

В Java SE её можно использовать:
This document is the specification of the Jakarta Bean Validation in Jakarta EE and Java SE.
Про Android я мало что знаю, но там, скорее всего, тоже есть что-то готовое.

Плюс к этому там используются исключения при валидации.

Если вы про Exception model, то это исключения, выбрасываемые в случае неправильной конфигурации валидатора.
Сама валидация возвращает Set<ConstraintViolation>.

[@Moriline]

Нет, я имел ввиду что при проверках(под капотом этой реализации) бросаются исключения, которые потом оборачиваются в Set<ConstraintViolation>. ValidationException — один из основных. Вот здесь больше описано про исключения.
А с JavaSE я был не прав. Но ведь такой подход применим и для других языков, а не только там где есть такие вещи как JSR-303, JSR-349, JSR-380.

[@ppikS]

Такой подход уже сто лет как используется везде и повсеместно, особенно в вебе.
Единственные исключения это сайты, где разработчики особо не заморачиваются.

А ещё вы можете возвращать код ошибки, а описание ошибок хранить на клиенте.
Или же можно возвращать несколько кодов ошибок, а ещё лучше использовать побитовую маску и объединить все ошибки в одно значение.

Почему то ещё сразу вспомнил WSDL.

[@Moriline]

Я думаю что данная статья и поможет использовать именно такой подход для валидации данных. А с Вашей стороны было бы хорошо подсказать: какие валидаторы лучше всего использовать в вебе. Вот Вы каким пользуетесь?

[@ppikS]

У меня есть свой, давно написанный шаблонный класс, который я дописываю под задачу. Максимально сурово контролируя все данные, с жёсткой типизацией, длинной, проверкой по спискам и тп.

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

А по поводу информирования пользователей, так же всё зависит от задачи и объёмов работ.
Если использую свой шаблонный класс, то он как раз возвращает код ошибок, так же есть шаблонный класс js который содержит практически тоже самое, так как не за чем гонять туда-сюда заведомо неверную информацию.

Бывает делаю и в тупую, где вся форма выдаёт ошибку или же не выдаёт. Но это опять же от проекта зависит и задач.

В данном случаи считаю нету типовых решений, есть только правила, до которых всем надо постепенно дойти, самое первое, это максимально возможно жёстко контролировать все входящие данные. А остальное придёт с опытом, как и собственные наработки.

[@Vadem]

Нет, я имел ввиду что при проверках(под капотом этой реализации) бросаются исключения, которые потом оборачиваются в Set ConstraintViolation. ValidationException — один из основных. Вот здесь больше описано про исключения.

Я в документ, что вы привели, не вчитывался, но похоже, что там как раз наоборот.
Результат валидации оборачивается в исключение, потому что этого требует платформа CUBA:

        Set<ConstraintViolation<Product>> product_violations = validator.validate(product);
        if (product_violations.size() > 0) {
            StringBuilder strBuilder = new StringBuilder();
            product_violations.stream().forEach(violation -> strBuilder.append(violation.getMessage()).append("; "));
            throw new CustomValidationException(strBuilder.toString());
        }

Если вы имеете ввиду примеры из Setting validator programmatically:

        quantityField.addValidator(
                new Field.Validator() {
                    @Override
                    public void validate(Object value) throws ValidationException {
                        if (value != null && value instanceof BigDecimal
                                && ((BigDecimal)value).compareTo(new BigDecimal(1000)) > 0) {
                            throw new ValidationException(getMessage("quantityIsTooBig"));
                        }
                    }
                }
        );

То там тоже исключения кидаются потому что этого хочет CUBA:

    @Deprecated
    interface Validator<T> extends Consumer<T> {
        /**
         * @param value field value to validate
         * @throws ValidationException this exception must be thrown by the validator if the value is not valid
         */
        void validate(@Nullable Object value) throws ValidationException;

        @Override
        default void accept(T t) {
            validate(t);
        }
    }

Но это уже личные проблемы платформы CUBA.
Ни спецификация, что я привёл, ни её реализации не требуют выброса исключений для возврата результата валидации и не делают этого.
Хотя и не запрещают этого, если фреймворк требует.

А с JavaSE я был не прав. Но ведь такой подход применим и для других языков, а не только там где есть такие вещи как JSR-303, JSR-349, JSR-380.

Можете привести пример языка, в котором нет готовой библиотеки для валидации?

[@Moriline]

Я же имел ввиду спецификации, а не библиотеки. Библиотек много(платформа CUBA, реализация от Hibernate и т.д.), но вот стандарта единого(такого как JSR-303, JSR-349, JSR-380) нет. К тому же многие пишут свои реализации валидаторов, а не используют готовые библиотеки.

[@lair]

но вот стандарта единого

Между языками? А зачем?