你有没有捕获异常,或抛出一个不会被捕获的异常？

Question

我已经处理了一些实例,我会抛出/重新抛出异常,知道它周围的代码会捕获特定的异常.但是,有没有时间你想要抛出异常,知道它不会被抓住？

或者至少,没有捕获异常？

除非处理权利,否则例外会立即停止申请？所以我想我问你是否想故意让你的应用程序死掉？

Answer 1

如果您的应用程序主要由其他客户端使用而不是独立的,那么在出现您不知道如何(或不想)处理的情况时抛出异常通常是有意义的,并且没有明智的做法你可以从中恢复的方式.客户端应该能够决定他们如何处理您可能抛出的任何异常.

另一方面,如果您的应用程序是端点,则抛出异常本质上会成为一种通知机制,以提醒人们某些事情已经发生了严重错误.在这种情况下,您需要考虑以下几点:

• 应用程序的持续运行有多重要？这个错误真的无法恢复吗？抛出异常并终止你的程序并不是你想要在航天飞机上做的事情.

• 您是否使用例外作为真实日志的代理？几乎没有理由这样做; 考虑一个真正的日志记录机制.捕获异常并让记录器解决发生的事情.

• 你想通过自己抛出异常来传达什么？问问自己抛出一个新例外的价值是什么,并仔细考虑是否没有更好的方法来做你想做的事情.

• 不捕获异常可能会使资源处于不良状态.如果您没有优雅地退出,通常不会为您清理任何事情.如果你需要这样做,请确保你理解你在做什么 - 如果你不想抓住它,至少考虑一个try-finally块,这样你就可以做一些整理.

Answer 2

我前一段时间遇到过一个非常好的规则:

当方法无法按照其名称所做的操作时抛出异常.

这个想法是一个例外表明出现了问题.在实施方法时,您不应该知道它是否会被正确使用.使用您的方法的代码是否捕获异常不是您的责任,而是使用您的方法的人的责任.

另一条遵循的规则是:

除非你知道你想用它做什么,否则不要捕捉异常.

显然,你应该在try ... finally块中包含清理代码,但是你不应该仅为了捕获它而捕获异常.而且你永远不应该默默地吞下异常.虽然有时您可能想要捕获所有异常(例如通过在C#中执行catch(Exception ex)),但这些异常并不常见,并且通常具有非常特定的技术原因.例如,当您在.NET 2.0或更高版本中使用线程时,如果异常从您的线程中逃脱,则会导致整个应用程序域卸载.但是,在这些情况下,您至少应将异常详细信息记录为错误,并在注释中提供说明.

Answer 3

当然。例如，如果您尝试在 Java 中将一些字节加载到字符串中：

try {
  String myString = new String(byteArray, "UTF-8");
} catch (UnsupportedEncodingException e) {
  // Platform doesn't support UTF-8?  What is this, 1991?
  throw new RuntimeExceptione(e);
}

在这种情况下，没有优雅降级，平台根本无法支持所需的操作。您可以根据需要在初始化时检查此条件，但是 String 的构造函数仍然抛出此异常，您必须处理它。要么，要么使用 Charset.forName() :)

Answer 4

通常,当然在应用程序的早期迭代中,不要捕获异常.通常情况下,从异常中恢复将需要某种业务规则,并且通常不会为您定义这些业务规则.如果您"处理"异常而不是让应用程序死亡,那么您很可能会为您的客户创建业务规则.不好.

为了捕获它而捕获每个异常的一般模式使我比我可以计算的更令人头疼.通常会有人在整个应用程序中放置某种通用异常处理代码,这不可避免地会隐藏错误或创建一些不需要的行为.(顺便说一下,捕捉然后不再重新抛出更糟糕.)

所以,我建议你问一下:"什么时候应该抓住一个例外？"