Как правильно организовать вывод сообщения об ошибке в Java-программе?

Question

[kyberorg]

Добрый день, Хабр!


Возник такой вопрос: как правильно реагировать на неправильные аргументы на входе?


Ситуация такая:

пишу запускалку для одного веб-сервера. По замыслу она может запускаться в двух режимах:

1) В режиме embedded (тогда ее конфигурируют в основном приложении)

2) В режиме standalone (тогда ей передают параметры через командную строку)


Сейчас сделано так:

Все аргументы валидируются в одном месте (в сеттерах объекта конфигурации) и в случае если параметр критичный (например, порт, на котором стартует сервер), то во вне выбрасывается исключение.


Ситуация усугубляется тем, что валидация происходит в конструкторе, то получается что даже конструктор выкидывает исключение (что мягко говоря не должно быть, судя советам в книге «Совершенный код»).

Answer 1

[serso]

Всё правильно делаете. Только если у вас приложение из консоли запускается я бы предложил использовать Commons CLI для парсинга входных аргументов.
Не вижу проблемы валидации в конструкторе (например), но если очень хочется изменить — введите статичный фактори метод, в который помесьтите всю валидацию, а конструктор сделайте приватным.

Я бы, наверное, сделал бы так: Input в виде Commons CLI Options, далее преобразование его в класс-структуру настройки (не зависимой от CLI, в случае режима embedded такде заполнение этой структуры) без валидации, статичный фактори метод с этой настройкой, где происходит вся валидации и выставление параметров бизнес объекта.

Answer 2

[KEKSOV]

«Обычно я пишу так» (с)

1. В конструкторе для все конфигурационных параметров задаются значения по умолчанию
2. Любыми способами — из переменных окружения, аргументов командной строки, кофигурационных файлов и т.п. пытаемся уточнить нашу конфигурацию
3. Создаем метод validate() — только в нем проверяем нашу конфигурацию на валидность и только в нем пишем ошибки, связанные с этим
4. Запускаем основную ветку пограммы

На псевдокоде это выглядит так
service = new TService();
service.loadConfig()
service.validateConfig();
service.doJob();

А в книжке все правильно написано — никаких исключений в конструкторах!

Comments

[serso]

никаких исключений в конструкторах

Это почему ещё? Только давайте конструктивно, вот, например, контр-размышления.

[kyberorg]

Спасибо за идею.
Небольшое уточнение:

Как защитить код от такого:

service = new TService();
service.loadConfig();
service.doJob(); //Тогда на этом этапе возможно будут ошибочные данные.

[serso]

И почему у вас loadConfig() отделён он validateConfig(), что будет если кто-то забудет вызвать второй метод?
Собственно, возникнет ситуация, что суеществеут instance сервиса, который не сконфигурирован (пусть, например, validateConfig вызван, но кинул исключение)

[KEKSOV]

Вот тут человек пишет:

One thing to be careful of about throwing exceptions in the constructor: because the caller (usually) will have no way of using the new object, the constructor ought to be careful to avoid acquiring unmanaged resources (file handles etc) and then throwing an exception without releasing them. For example, if the constructor tries to open a FileInputStream and a FileOutputStream, and the first succeeds but the second fails, you should try to close the first stream. This becomes harder if it's a subclass constructor which throws the exception, of course… it all becomes a bit tricky. It's not a problem very often, but it's worth considering.

мой практический опыт подтверждает — исключение в конструкторе это путь к проблемам и неуловимым ошибкам

И почему у вас loadConfig() отделён он validateConfig()

1. Исключительно для наглядности, его вызов можно поместить в конце loadConfig()
2. validateConfig можно вызвать в любой момент, без вызова loadConfig во время рантайма. Это уже просто на автомате у меня — каждое дейтвие оформляю в отдельную функцию — легче дебажить и читать код