24

谁能告诉我异常可能有什么原因，与“抛出”条款不兼容

例如：

class Sub extends Super{

    @Override
    void foo() throws Exception{

    }

}

class Super{

    void foo() throws IOException{

    }
}

Exception 异常与 Super.foo() 中的 throws 子句不兼容

4

4 回答 4

32

如果没有完整的代码示例，我只能猜测：您正在覆盖/实现子类中的方法，但子类方法的异常规范与超类/接口方法的异常规范不兼容（即不是子类）？

如果声明基方法根本不抛出异常，或者例如java.io.IOException（这是java.lang.Exception您的方法的子类试图在此处抛出），则可能会发生这种情况。基类/接口的客户期望它的实例遵守基方法声明的契约，因此Exception从该方法的实现中抛出会破坏契约（和LSP）。

于 2012-05-09T09:38:46.553 回答
0

要修复它，请使用RuntimeException

public T findById(long id) throws RuntimeException {
    try {
          return whatEver.create();
    } catch (SystemException e) {
          throw new RuntimeException(e);
    }
}

希望这可以帮助。

于 2013-09-25T09:42:00.147 回答
-1

检查异常旨在用于方法可能期望其调用者准备处理可能出现的某些问题的情况。如果调用者 ofBaseFoo.Bar()不需要处理 a FnordException，那么方法DerivedFoo.Bar()不能期望它的调用者处理 a FnordException（因为它的许多调用者将是那些没有准备好BaseFoo.Bar()抛出它的调用者）。

从概念上讲，这很棒。在实践中，并没有那么多。问题是语言中检查异常的设计假设要么没有调用者准备好优雅地处理特定问题，要么所有调用者都准备好处理它。实践中的正常情况是调用者没有准备好处理异常——即使是一些调用者可能能够处理的异常。大多数情况下，当代码收到它没有明确期望的已检查异常时，正确的操作过程是将其包装在未检查异常中并抛出该异常。具有讽刺意味的是，最简单的做法——添加“抛出”子句并让检查的异常冒泡，可能是最不可能正确的做法。虽然有一些情况（例如IOException) 在这种行为有意义的情况下（例如，当尝试从文件中读取集合时，读取一项时的 I/O 错误是读取集合时的 ​​I/O 错误），从嵌套方法调用中抛出的异常将表示与外部方法抛出的相同类型的异常不同的条件，并且准备处理后者的代码可能不准备处理前者。

在您的情况下，您最好的选择可能是将其捕获IOException并包装在派生自 的其他类型中RuntimeException，并意识到您的调用者不太可能处理它。

于 2013-04-16T17:59:59.777 回答
-1

确保您在界面中声明了 throw。如果您这样做了，但问题仍然存在 - 尝试保存/重建项目。

于 2016-06-29T20:20:27.107 回答