抛出接口中未定义的异常
当您需要抛出未在您正在实现的接口中定义的异常时，应遵循的最佳实践是什么？
下面是一个示例：
public interface Reader
{
public abstract void read() throws IOException;
}
public class CarrotReader implements Reader
{
public void read() throws IOException {}
}
public class CupcakeReader implements Reader
{
public void read() throws IOException, CupcakeException {}
}
在本例中，您在读取纸杯蛋糕时发生了特定的异常，因此您想要抛出与此相关的异常。 然而，Reader在它的接口中没有定义这种类型的异常，那么你该怎么办呢？ 此外，将 CupcakeException 添加到 Reader 接口中的 throws 子句是没有意义的，因为这种类型的异常特定于 < em>CupcakeReader。 解决这个问题的一种方法是让Reader定义read，这样它就会抛出一些父类型，例如Exception，但随后你会丢失该对象的上下文例外。 在这种情况下你应该做什么？ 谢谢！
提出的另一个有趣的情况涉及您无法控制的界面。 在这种情况下，表明出现问题的最佳方式是什么？
出于说明目的，这里是另一个示例：
public interface Reader
{
public abstract void read();
}
public class CupcakeReader implements Reader
{
public void read() throws CupcakeException {}
}
在这种情况下，您无法更改 Reader，但您想要指示 CupcakeReader 的读取发生了问题方法。
What is the best practice to follow when you need to throw an exception which was not defined in an interface that you are implementing?
Here is an example:
public interface Reader
{
public abstract void read() throws IOException;
}
public class CarrotReader implements Reader
{
public void read() throws IOException {}
}
public class CupcakeReader implements Reader
{
public void read() throws IOException, CupcakeException {}
}
In this case, you have a specific exception that occurs when reading cupcakes, so you want to throw an exception related to this. However, Reader doesn't define this type of exception in its interface, so what do you do? Furthermore, it doesn't make sense to add CupcakeException to the throws clause in the Reader interface, because this type of exception is specific to CupcakeReader. One way around this is to have Reader define read such that it throws some parent type, like Exception, but then you lose the context for the exception. What should you do in this situation? Thanks!
Another interesting situation that has been brought up involves an interface over which you have no control. In this case, what is the best way to indicate that a problem has occurred?
For illustrative purposes, here is another example:
public interface Reader
{
public abstract void read();
}
public class CupcakeReader implements Reader
{
public void read() throws CupcakeException {}
}
In this case, you cannot change Reader, but you want to indicate that a problem has occurred in CupcakeReader's read method.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您可能必须创建预期类型的异常。
You may have to create an exception of the expected type instead.
使用名为 ReaderException 的东西作为异常层次结构的根接口。 ReaderException 还将提供由于较低级别的异常而引发的其他异常的链接。
Use something called ReaderException that will serve as the root interface of your exception hierarchy. ReaderException will also provides a link to other exceptions that get thrown due to lower level exceptions.
异常是接口的一部分。 如果可以重新定义接口，请为接口中的所有异常定义通用父级。
您还可以将 CupcakeException 设为 IOException 的子级。
Exception is part of the interface. Define a generic parent for all your exceptions in the interface if you can redefine the interface.
You can also make CupcakeException a child of IOException.
只是不要使用检查异常。
您展示的示例是检查异常不好的原因之一。
主要原因是纸杯蛋糕阅读器的用户必须处理你的异常，无论他是否对此感兴趣。
因此，不要：
你强迫他这样做：
想想哪一个更好，更具可读性并且更不容易出错，然后停止使用受检查的异常。
编辑：
我对负面评价感到惊讶。 还有人认为检查异常很棒吗？ 如果是这样，这里有一些参考，为什么你不应该使用检查异常：
Just don't use checked exceptions.
The example you showed is one of the reasons checked exceptions are bad.
The main reason though is that the user of your cupcake reader will have to handle your exception regardless of whether he is interested in it or not.
So instead of:
You are forcing him to do this:
Think which one is better, more readable and less error prone and just stop using checked exceptions.
EDIT:
I am surprised with the negative rating. Are there people who still think that checked exceptions are great? If so here are some references why you shouldn't use checked exceptions:
也许您可以创建一个抽象 ReaderSpecificException 类，将其放入接口中，然后
此抽象类的子类 CupcakeException。
Perhaps you could make an abstract ReaderSpecificException class, put it in the Interface, and
subclass CupcakeException from this abstract class.
如果您创建一个更高的抽象异常来作为 CupCakeException 的基类，您就不会像将 CupCakeException 添加到 Reader 接口那样将 Reader 接口绑定到特定的实现。
如果您不让一个异常从另一个异常继承，则会出现 异常类中的构造函数，将 throwable 作为第二个参数，就像 Thorbjørn Ravn Andersen 在他的简短代码示例中展示的那样。 这使您能够生成更抽象的异常，并且代码中需要了解更多信息的每个部分都可以查找更高异常的原因，而不仅仅是“有错误”。
If you create a higher abstract exception that works as a base class for CupCakeException you don't bind the Reader Interface to a specific implementation like you would be doing if you added the CupCakeException to the Reader interface.
If you don't let one Exception inherit from another there is a constructor in the exception class that takes a throwable as second argument like Thorbjørn Ravn Andersen allready showed in his short code example. The enables you to generate a more abstract exception and every part of your code that needs to know more then just "there is an error" can look for the cause of the higher exception.