Относительно оригинального кода:
synthesizer = Central.createSynthesizer(generalDesc);
if (synthesizer == null) {
// (1) throw NPE explicitly
throw new NullPointerException("No general domain synthesizer found.");
}
// (2) let the JVM throw the NPE when dereferencing
synthesizer.allocate();
Я полагаю, что бросать NPE, как показано здесь, можно, но с огромными предостережениями. Предостережение, при котором это нормально, только в том случае, если аргумент NPE ctor является достаточно описательным (и, мы надеемся, уникальным) сообщением (которое, мы надеемся, извлечено из константы или набора ресурсов). Еще одно предостережение заключается в том, что ваш главный приоритет состоит в том, чтобы вывести вещи из дверь, и такие дела, это будет считаться приемлемым быстрым и грязным решением.
В идеальных условиях я предпочитаю использовать исключения, специфичные для недопустимых конфигураций. А когда они недоступны, либо использовать подклассы NPE (например, NullArgumentException ) Apache Commons Math, либо старые исключения, найденные в Apache Common Lang 2.x . Это моя позиция для NPE и исключений типа IllegalArgument. Я не обязательно согласен с позицией Apache Common Lang о предпочтении использовать стандартные исключения JDK над более семантически значимыми исключениями. Но это только я, и я схожу с касательной ...
... так что вернемся к первоначальному вопросу. Как я уже говорил ранее, бросать NPE, как это, можно быстро и грязно (когда вы находитесь в одном из тех «нужно вытащить этот хрен !! (10 + 1)» вида ситуаций.
Обратите внимание, однако, что это NPE, вызванный проблемой конфигурации приложения или системы, как вы ее правильно определили. Таким образом, NPE не является основной причиной, вследствие симптома или следствия другого состояния ошибки (в данном случае, ошибки конфигурации или среды).
Central.createSynthesizer возвращает ноль, если не может найти подходящий
синтезатор, который чаще всего вызван отсутствием речи. свойства
файл. Так что дело в неправильной настройке системы, и довольно
невосстанавливаемые из во время выполнения, а не обстоятельства, которые необходимо
обрабатываться программно.
Неустранимость не является достоверной. Прикладная программа может иметь другие способы обработать эту ситуацию программно.
Как таковой, я считаю, бросая
NullPointerException является допустимым ответом, поскольку он указывает на ошибку
(не в коде, а в развертывании программного обеспечения). Но так как
объект синтезатора разыменовывается в следующем операторе, если
Я просто позволил JVM бросить NPE для меня и сохранить нулевую проверку?
Я бы не стал этого делать, даже при обстоятельствах, которые можно достать из двери . У NPE, брошенного таким образом JVM, будет очень неинформативное сообщение в этом. В общем, проверяйте все на NULL и выбрасывайте описательное исключение (NPE или иное), когда вы сталкиваетесь с ним.
Не проверяйте NPE, если вы можете гарантировать, что все, что вы получаете (например, параметры), уже проверено на NPE (в порядке, предусмотренном контрактом).
Добавление: учитывая, что speech.properties загружается, когда JVM
Запуски должны существовать в файловой системе в (обычно) "user.home" или
"java.home / lib", удивительно, что createSynthesizer не
прямо вверх бросить NPE (это то, что я написал изначально в
Фрейдовский промах), когда он не может найти его, но вместо этого возвращает ноль.
Опять же, это потому, что ответ на эту ситуацию зависит от приложения. Приложение может решить перейти в режим limping с частичной функциональностью вместо сбоя и прожига до основания. Если createSynthesizer должен был выбросить NPE, тогда разработчик API заставляет разработчика приложения принять более позднее поведение или пойти на несколько большие длины, чтобы реализовать режим операций "limping" (с помощью использования перехват / попытка вместо простого теста if-null.
Я думаю, что выбрасывать NullPointerException - это правильно
здесь, потому что это указывает на фактическую ошибку в развертывании
программное обеспечение.
Опять же, только если NPE - это быстрое и грязное решение, чтобы вытащить вещи из двери.В этих условиях это нормально.Лучший подход - определить, что это, ошибка конфигурации.
Так что было бы лучше иметь исключения для конкретных приложений, такие как IllegalConfigurationException или InvalidConfigurationException или IncompleteConfigurationException .Мне не нравится использовать java.lang.IllegalStateException для таких случаев, потому что это не вызвано вызовом чего-либо в недопустимом состоянии.Недопустимое состояние достигнуто из-за неверной конфигурации.Может быть, я играю в семантические игры, но в таких случаях есть какая-то странность в использовании IllegalStateException (я знаю, что я субъективен).