异常是否破坏封装？

Question

首先，当您不想担心实现的细节时，会创建一个类或库，但是您需要知道该类的内部工作方式，以正确处理它可能抛出的异常。

这是否违背了封装和信息隐藏的原则？或者我完全错了吗？

当然，我可以有一个通用的try/catch块拦截所有的异常，但这绝对是一个不好的做法。

那么，如何在不知道可能引发的每个异常的细节的情况下提出良好的异常处理策略呢？

Answer 1

设计良好的类或库将记录它作为接口的一部分抛出的异常，甚至可能甚至可以定义自己的异常类层次结构。例如，如果磁盘已满，foo子类可能会抛出“foo持久性异常”，而另一个子类会在网络关闭时抛出一个。作为调用者，您会捕获一个foo持久性异常，因为您担心数据未被保留。不应期望您编写专门用于磁盘满，网络关闭，磁盘不存在，磁盘写入错误，子空间收发器干扰的代码，& c。

可能出现这种情况，您不能对其中的很多事情做很多事情。

Answer 2

这不是那样的;它适用于使用最终产品的最终用户或者“不需要知道内部实现”的类，但是您肯定知道它，因此可以相应地纠正错误机制。

顺便说一句，这就是任何API带有良好文档的原因......所以其他开发人员至少知道它的一些内部工作。

希望这清除了这个想法。

Answer 3

类库不必抛出其代码抛出的相同异常。对于无法在内部处理的预期异常，它应该映射到备用异常类型，API消费者不容易理解“原始”异常。 API消费者应该能够将预期的异常视为API的输出，正如API的任何其他使用产品一样。另一方面，意想不到的例外是API开发人员和消费者的另一种蜡烛......

Answer 4

首先，一类或库创建时你不想 担心的实施细节，但你需要 知道类妥善处理异常的内部运作 它可能会抛出。

这是不是破坏了封装和信息隐藏的原理 ？或者我完全错了吗？

如果由于某些运行时错误而导致无法履行其承诺，并且无法从该状态恢复，则应引发异常。必须在接口/文档中指定可能抛出什么异常。我不明白这是如何破坏封装的。另一方面，使用返回码不能强制调用者处理特殊错误，即使通过明确忽略它。

当然，我可以有一个通用的try/catch块来拦截所有异常，但这绝对是一个不好的做法。

这是如果你使用没有明确地指出可能会被抛出异常是什么接口的设计以及由谁/ what_function

所以，我怎么能拿出良好的异常处理策略没有 知道可能引发的每个异常的详细信息？

“细节”实际上是例外规范，这就是你所需要知道的。同样，它应该是文档/界面的一部分。

无论如何，异常应该很少发生，也许这就是为什么有人给它们命名为异常。如果它发生得太频繁，那么有人不会再将它们命名为例外，但“平常”或其他事情以及正常，无异常的“代码”将成为例外:)

如果您工作太多，/catch bollocks，那么代码有问题。