2014-12-05 2 views
1

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

Например, вы можете указать пользовательское хранилище ключей с пользовательским псевдонимом, который будет использоваться для соединений WebService (вместо JVM по умолчанию javax.net.ssl.keystore).

Во время выполнения мы можем обнаружить, что этот псевдоним не существует в хранилище ключей, поэтому нам может потребоваться исключение. Поскольку это ключевая часть приложения (и мы не можем ожидать, что приложение будет функционировать должным образом до тех пор, пока не будет исправлено конфиг), я думаю, что бросать исключение Unchecked Exception - хорошая идея здесь.

Я прав, так думая?

Имеет смысл создать обычай ConfigurationException (который расширяет RuntimeException), чтобы выбросить в этом случае?

ответ

2

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

Если ваше требование: «Приложение не должно продолжаться, если конфигурации не верны», и нет способа, которым пользователь может работать, чтобы обойти его (в блоке try-catch), тогда я не вижу причин, чтобы сделать его проверенным Исключение (Почему пользователи делают ненужную работу, если мы знаем, что это бесполезно).

Итак, в этом случае я бы также пошел на беспрепятственное исключение.

+0

Спасибо за ваш ответ. Не могли бы вы пойти с по умолчанию «RuntimeException» или создать расширенное специальное исключение, указывая конкретно на конфигурацию? – Davio

+1

Я поеду на заказ ... (Я не тот, кто ответил, но я согласен с ответом) – Hichamov

+0

Я бы пошел на заказ, так как это обеспечило бы намного более тонкое управление. – Ouney

0

Я думаю, вы должны создать проверенное исключение, и когда вы его поймаете, завершите программу в блоке catch после отображения сообщения или чего-то еще. Исключенные исключения предназначены для ошибок программирования и должны быть исправлены разработчиком. Проверьте исключения на условия, которые могут произойти, но мы не контролируем его. Вы знаете, что файл конфигурации может быть поврежден, но вы не можете предотвратить его и не можете его контролировать. Я бы пошел с проверенным исключением.

0

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

При проверке ввода пользователем прямого ввода пользователем или ввода пользователем через файл конфигурации исключение не указывает на ошибку. Поэтому это должно быть проверенное исключение, чтобы напомнить программисту, который называет ваш метод, что исключение вряд ли произойдет и должно быть поймано. Уловив исключение, вы можете создать удобное для пользователя сообщение об ошибке, которое указывает на решение. (Вы не хотите, чтобы конечный пользователь видел сообщение сгенерированное Java Exception in thread ...!)

Смежные вопросы