Как правильно возвращать результат операции (успех/ошибка) в Java методе без вывода в консоль?

@Skyzi · Регистрация: 17.01.2026

Студворк — интернет-сервис помощи студентам

Я пишу backend приложение на Java и хочу, чтобы методы явно сообщали о результате своей работы. При этом не хочу использовать System.out.println(), так как, думаю,что это не подходит для реальных проектов. Я хочу этот результат выдавать пользователю, чтобы было ясно успешная операция или нет.

Пример метода:

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@Override
    public OperationResult addProductToSystem(Product product) {
        if (product == null) {
            throw new NullPassedException("Было передано неверное значение!");
        }
 
        if (product.getArticle() <= article) {
            product.setArticle(generatorArticle());
        }
 
        if (products.containsKey(product.getArticle())) {
            return new OperationResult(false, "Данный товар уже находиться в системе!");
        }
 
        products.put(product.getArticle(), new Product(product));
        return new OperationResult(true, "Товар успешно добавлен в систему!");
    }

Я подумал создать record:

Java
1
public record OperationResult(boolean success, String message) {}

и вместо void возвращать OperationResult. Но не уверен, насколько это соответствует реальным Java-проектам.

p.s. я только изучаю backend на java, но хочется писать, чтобы было похоже на реальный проект

@Thousbe · 18.01.2026, 21:52

Идею с System.out необходимо развить до логгера. При локальном запуске для отладки делаем вывод в System.out, а в промышленной эксплуатации вывод в авторотируемые файлы на диске - это основа с которой начинается разбор любого инцидента. Главное снабжать логи сквозным идентификатором запроса, чтобы видеть маршрут того, как мы дошли до жизни такой... просматривая логи. Если нельзя сделать, например,

Bash
1
cat file | grep "[client_id=111]"

то грош цена таким логам.

По основному вопросу всё сложней.

Если это внешние http-запросы, то желательно начать со схемы валидации запросов и ответов. От выразительности схемы валидации будет зависеть то, сколько проверок придётся выполнять непосредственно в коде, а сколько сможет автоматически отбрить валидатор.
Схема для наших ответов также позволит формализовать какие-то основные шаблонные ошибки и их формат. Специфические ошибки могут иметь свой формат ответа.
В общем случае, ответ часто представляет собой два поля - resultCode и value.
Если запрос выполнен без ошибок, то это (resultCode=0, value="OK"), иначе какой-то код и краткое или не очень описание.
Примеры организации кодов ошибок можно посмотреть на примере ORA (Oralce) и PG (PosgreSQL), либо HTTP, когда код ошибки сквозной и уникальный и сразу понятна ошибка, либо код указывает на группу ошибок и надо изучать текст ошибки для локализации.

Как реализовать это в коде - это вопрос на уровне подхода и/или идеологии в организации этого самого кода.

Один из подходов это бросать исключения в коде, наподобие NullPassedException. Какой-нибудь верхнеуровневый обработчик, например, обработчик на уровне контроллера Spring'а, по типу и параметрам исключения сформирует внешний ответ.
Либо в стиле адептов Go - это подход в пробросе ошибки/состояния из места возникновения до верхнеуровневого обработчика.
Редко логику реализуют в виде конечного автомата, когда для всех ошибок есть заданные состояния и соответствующие обработчики, которые будут формировать итоговый ответ.

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

Горячий метод, который часто вызывают, особенно в циклах, будет бить по производительности, если будет бросать исключение, а не возвращать обёртку с константой ошибки или саму константу;
Повальный stream'оз головного мозга будет создавать негативные возмущения в ваш адрес, если метод будет иметь проверяемое исключение в объявлении, либо просто бросать исключение

Новые блоги и статьи Все статьи Все блоги /
Автозаполнение реквизита при выборе элемента справочника Maks 27.03.2026 Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. При выборе "Спецтехники" (Тип Справочник. Спецтехника), заполняется. . .	Сумматор с применением элементов трёх состояний. Hrethgir 26.03.2026 Тут. https:/ / fips. ru/ EGD/ ab3c85c8-836d-4866-871b-c2f0c5d77fbc Первый документ красиво выглядит, но без схемы. Это конечно не даёт никаких плюсов автору, но тем не менее. . . всё может быть. . .	Автозаполнение реквизитов при создании документа Maks 26.03.2026 Программный код из решения ниже размещается в модуле объекта документа, в процедуре "ПриСозданииНаСервере". Алгоритм проверки заполнения реализован для исключения перезаписи значения реквизита,. . .	Команды формы и диалоговое окно Maks 26.03.2026 1. Команда формы "ЗаполнитьЗапчасти". Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. В качестве источника данных. . .
Кому нужен AOT? DevAlt 26.03.2026 Решил сделать простой ланчер Написал заготовку: dotnet new console --aot -o UrlHandler var items = args. Split(":"); var tag = items; var id = items; var executable = args;. . .	Отправка уведомления на почту при создании или изменении элементов справочника Maks 24.03.2026 Программная отправка письма электронной почты на примере типового справочника "Склады" в конфигурации БП3. Перед реализацией необходимо выполнить настройку системной учетной записи электронной. . .	модель ЗдравоСохранения 5. Меньше увольнений- больше дохода! anaschu 24.03.2026 Теперь система здравосохранения уменьшает количество увольнений. 9TO2GP2bpX4 a42b81fb172ffc12ca589c7898261ccb/ https:/ / rutube. ru/ video/ a42b81fb172ffc12ca589c7898261ccb/ Слева синяя линия -. . .	Midnight Chicago Blues kumehtar 24.03.2026 Такой Midnight Chicago Blues, знаешь?. . Когда вечерние улицы становятся ночными, а ты не можешь уснуть. Ты идёшь в любимый старый бар, и бармен наливает тебе виски. Ты смотришь на пролетающие. . .