2015-03-31 57 views
0

我经常遇到同样的问题。在我的Java应用程序的核心,我有方法抛出一个无法由任何方法调用者处理的异常。我必须将这些例外发挥到主要方法。所有这些异常总结,所以我有很多关于我的应用程序更高级别的抛出声明。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。如果没有启动NodeJ,我的应用程序就没用了。没有方法可以捕捉到这个异常,这只是要求为我的应用程序工作。所以这个例外几乎会在整个应用程序生命周期中产生泡沫。我有其他的管理者也是这样做的(一个ConfigurationManager会抛出一个异常,如果配置路径错误的话)。总而言之,它总结了许多投掷语句中的每一种方法的更高层次,我甚至不记得那种例外的原因。

你会如何处理这个问题?我必须做一些完全错误的事情,因为我找不到描述我的问题的类似帖子!

问候 迈克

更新

我刚出土我好老有效的Java书。作者(在谷歌一个Java架构师)写了下面的有关例外:

...使用检查可恢复条件和运行 例外编程错误例外。

...

如果没有明显的复苏是否是可能的,你可能会更好过使用未经检查的异常...

在我的情况下,它显然是不可恢复的,所以抛出一个运行时异常是最好的选择。我一直认为应该阻止运行时异常,这改变了我对Java中异常的看法。

回答

0

我不喜欢检查异常。我用什么做的(但不是一个很好的解决方案)被抓检查异常,并重新把它作为一个运行时异常这样:

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

的检查异常“E”作为一个参数传递RuntimeException的。这样,我将检查转换为未经检查的异常。但正如我所说,这不是一个好的解决方案,它可能会导致更多的调试问题。当一个异常被“检查”时,这往往是因为描述的错误是“严重的”。

0

一种解决方案是创建您自己的更一般的异常类,它将扩展Exception并将未处理的异常作为原因包装到您自己的异常中。这样你至少可以减少方法签名的一些异常。例如:

创建新类StartupExceptionConfigurationException并在启动阶段将其捕获为主要异常之后抛出它。

此外,如果你想让StartupException extends RuntimeException)你不必声明这种例外。

另一种方式是一切包装成RuntimeException

如果abowe不能满足您的需求比这可能是设计缺陷,(如果你真的无法处理它),你将不得不面对它。

1

一种可能的方法是尽可能地将Exception与原产地进行处理,在那里您有足够的信息来决定做什么。

正如你所说,如果你把所有的Exception都捕获到了最高级别,你就失去了非常重要的上下文,因为这给出了问题发生的原因和方式(希望有几种方法可以解决它) )。

你说例如没有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来处理你的代码流。