抛出IOException而不是Exception

时间:2014-05-05 19:55:37

标签: java exception ioexception

我有从整个代码中的许多其他方法调用的method1()。这是该方法的签名:

 public void method1(final Properties properties) throws IOException {}

调用此方法的所有方法也会抛出IOException。

method1()中的实际代码已更改,因此现在不再使用IOException,而是抛出一些其他异常,这些异常会再次扩展Exception和 而不是 IOException。

我不想更改调用method1()的所有方法的签名。

是否可以创建IOException并仍然从method1()抛出IOException,因此调用method1()的方法?

如下所示:

 Try {
  // code
 } catch (Exception e) {
   throw new IOException(e.getCause());
 }

3 个答案:

答案 0 :(得分:4)

,您应该这样做,因为您会混淆每个其他开发人员阅读您的代码或阅读堆栈跟踪。

从软件设计的角度来看,错误发生的时间要早​​得多。 如果您的代码类似于API并且被其他人使用,您最好使用Custom-Exceptions并将IOException包装为根本原因。

如果您拥有完整的源代码,则应重构源代码并添加另一个异常签名。

答案 1 :(得分:1)

您需要将原始异常保存为原因,因此您不会丢失原始消息或堆栈跟踪。在您的代码示例中调用e.getCause()正在跳过您捕获的异常并获取原因,这是可疑的。

此外,最好指定方法捕获的特定异常,而不是使用catch-all Exception类型。捕获异常会导致NullPointerExceptions被捕获之前没有被捕获。

这里要做的最好的事情是将方法抛出的异常更改为不会让实现细节渗透到调用者的自定义类型。您的方法签名应更改为

public void method1(final Properties properties) throws SomeCustomException {
    try {
        .... // do whatever
    } catch (AException | BException | CException e) {
        throw new SomeCustomException(e);
    }
}

答案 2 :(得分:0)

这将在技术上有效。

但是,抓住ExceptionThrowable几乎每次都是一个坏主意(就像扔掉它们一样),因为除了RuntimeExceptions之外,你还会捕获所有其他异常。

如果你可以改变所有调用类的代码(即你没有开发框架/库),你应该这样做。因为我认为你的意思是method1()现在抛出一个更具体的类型。

您也可以考虑投放一个不需要捕获的RuntimeException子类型,并且对于无法纠正的错误(例如错误的配置)是一个好主意。 (参见罗伯特·马丁的清洁代码