重新引发异常问题

您可能需要捕获一个异常(例如,找不到文件)并进行一些处理-例如,如果打开两个文件,而第二个文件丢失,则在继续之前,您需要再次关闭第一个文件,这样就不会让它保持打开状态。

然后您可能想告诉调用者发生了一个错误,所以您要重新抛出相同的异常,或者抛出一个新的异常,描述这个问题。

在某些情况下,如果您得到一个异常,您的代码就无法知道它是否是一个错误(例如,如果要求您加载一个XML文件,但您得到一个未找到的文件异常,这是一个错误,还是应该返回一个空的XML结果?)在这些情况下,您要么想要重新抛出异常,要么不完全处理异常,让调用代码决定如何处理问题。

你的第二点是第一点的答案。有时,较低级别的功能对应用程序上下文的了解不够,无法知道正确的操作应该是什么。例如,如果打开要读取的文件失败,因为没有该名称的文件,那么应用程序可能希望请求其他文件,或者中止整个操作,或者其他任何操作。在某种程度上,应用程序的某些部分将负责做正确的事情,当然,除非程序崩溃是可以接受的行为。

回答第二个问题-只有在可以对立即块执行任何操作时,才需要处理立即块中的异常:例如,关闭与数据库的连接、关闭流、使用不同参数重试或重试、记录异常(如果更高级别上没有异常通用处理程序)。可能只有直接的代码块知道这些细节并能处理它们。调用块需要知道发生了错误,它们可能更好地知道如何处理异常。

例如,即时块与文件一起工作。调用者可能会尝试从不同的位置(在“探测”过程中)打开一个文件,并忽略几个错误,只要至少一个成功。代码的另一部分可能将第一次失败的尝试视为错误。调用程序块可能会选择通知用户发生了错误,可能会让她/他知道一些关于如何解决问题的有用信息。此外,还可以提供一种方法来通知支持人员问题“某种对话允许用户请求帮助、描述问题并发送消息。在这个消息中,您可以附加日志,一些关于环境的信息,如操作系统、框架版本、程序、浏览器功能,无论您需要什么来诊断问题(如果用户允许您这样做的话)。

如果捕获异常的方法能够满足其构造,则该异常将被“处理”。例如,例行程序的合同 OpenRecentDocument 当用户从“最近使用的文件”菜单中选择一个项目时,它会被调用,可能指定它必须(1)成功打开一个文档窗口,或(2)尝试打开一个文档窗口失败,回滚由于尝试而产生的任何副作用,并通知用户发生了什么。如果 打开接收文档 在试图打开文件时捕获一个异常,但它能够回滚来自尝试的任何副作用并通知用户,该例程将满足其约定,因此应返回而不重新引发该异常。

其中一个不幸的“抓到”是,没有任何标准方法可以让抛出异常的例程指示其尝试的操作是否导致无法回滚的副作用。例如,没有固有的方法来区分 InvalidOperationException 在更新共享数据结构(这意味着其他打开的文档可能已损坏)时,从 无效操作异常 在更新与加载的文档相关联的数据时发生,即使有人已经预料到后一种可能性并提供给它。最好的办法就是抓住 无效操作异常 在后一种情况下,在发生异常的位置附近可能会发生这种情况,将该异常封装在其他异常类型中,并抛出该异常,或者让数据结构维护“对象已损坏”标志,并确保如果发现数据结构已损坏,则将来对其执行的所有操作都将尽可能干净地失败。两种方法都不优雅。更常见的方法,可能被描述为“最好的希望”,通常是有效的。