Java Исключения, которые невозможно обработать

Question

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

E.g. У меня есть класс NodeJsManager.java в основе моего приложения:

public class NodeJsManager { 

    public static void startNodeJs() throws ExecuteException { 
     // Code to start NodeJs Server goes here 
    } 

} 

Для запуска NodeJs сервера, я должен выполнить что-то в командной строке. Я могу сделать это с классом apache org.apache.commons.exec.CommandLine. Но он выдает ExecuteException, если выполнение завершено с кодом ошибки. Без запуска NodeJs мое приложение бесполезно. Никакой метод не может поймать это исключение, это всего лишь требование для моего приложения для работы. Таким образом, исключение создаст пузырь практически весь жизненный цикл приложения. У меня есть другие менеджеры, которые делают то же самое (ConfigurationManager, который генерирует исключение, если неправильный путь конфигурации). Все вместе он суммирует во многих высказываниях при каждом методе на более высоком уровне, где я даже не помню причины этого исключения.

Как вы справитесь с этой проблемой? Я должен сделать что-то совершенно неправильное, потому что не могу найти похожие сообщения, которые описывают мою проблему!

С уважением Майк

Update

Я просто раскопали мой хороший старый Эффективное Java книги. Автор (Ява архитектор Google) писал о Исключении:

... использование проверяемого исключений для извлекаемых условий и выполнения исключений для ошибок программирования.

...

Если не ясно, возможно ли восстановление, вы, вероятно, лучше использовать непроверенное исключение ...

В моем случае это явно не возмещено, поэтому бросать исключение во время выполнения - это путь. Я всегда думал, что исключение во время выполнения должно быть предотвращено, это меняет мою точку зрения об исключениях в Java.

Answer 1

Мне не нравятся проверенные Исключения. Что я использую, чтобы сделать (но НЕ хороший раствор), чтобы поймать проверяемое исключение и повторно бросить его в качестве среды исполнения Exception следующим образом:

catch (ExecuteException e) { 
    throw new RuntimeException (e); 
} 

Проверенный Exception «е» передается в качестве параметра RuntimeException. Таким образом, я конвертирую проверенное в исключение. Но, как я уже сказал, это нехорошее решение, и это может вызвать проблемы с отладкой, которые он решает. Когда исключение «проверено», оно, как правило, связано с тем, что описанная ошибка является «серьезной».

Answer 2

Одним из решений было бы создать ваш собственный, более общий класс исключений, который будет распространять Exception и обернуть необработанные исключения как причины в ваше собственное исключение. Таким образом, вы можете по крайней мере уменьшить некоторые исключения из подписи методов.Пример:

Создайте новый класс StartupException или ConfigurationException и выбросьте его с основным исключением после того, как он поймает его как причину во время фазы запуска.

Более того, если вы сделали бы StartupException extends RuntimeException), вам не пришлось бы объявлять такое исключение.

Другой способ, чтобы обернуть все в RuntimeException

Если abowe не удовлетворяет вашим потребностям, чем это, вероятно, дизайн изъян, (если вы действительно не можете справиться с этим), что вам придется иметь дело с ним.

Answer 3

Один из возможных подходов - иметь дело с Exception как можно ближе к тому месту, где оно было создано, где у вас достаточно информации, чтобы принять решение о том, что делать.

Как вы сказали, если у вас есть все Exception s, которые были обнаружены на самом высоком уровне, вы теряете контекст, который действительно важен, поскольку это дает информацию о том, почему и как возникла проблема (и, надеюсь, несколько способов исправить это).

Вы сказали, например, что ваше приложение без сервера NodeJS бесполезно, тогда, вероятно, способ сделать это будет иметь NodeJSManager (если такая вещь существует: D, я предполагаю), чтобы не бросать, но предотвратить запуск приложения вообще, что-то вроде

NodeJSManager nodejsManager = new NodeJSManager(); 
boolean succeeded = nodejsManager.tryToStart(); 
if (!succeeded) { 
    // guard, it's useless to proceed 
    // cleanup and exit 
} 

я назвал этот метод tryToStart, потому что может случиться так, что сервер не запускается, вы имеете дело непосредственно с исполняемыми файлами и файловой системы, так что я бы сказал, что это не настолько исключительным (но, вероятно, это только вопрос вкуса).

Важно, чтобы вы указали, что ваше приложение запускается в виде серии проверок, например узла и конфигурационных, без необходимости иметь дело с Exception s для обработки потока вашего кода.