如何从未经检查的异常中恢复？

StackOverflow https://stackoverflow.com/questions/33497

  •  09-06-2019
  •  | 
  •  

题

如果您想以相同的方式处理每个失败，例如通过记录它并跳到下一个请求、向用户显示消息并处理下一个事件等，则未检查的异常是可以的。如果这是我的用例，我所要做的就是在系统的高层捕获一些通用异常类型，并以相同的方式处理所有内容。

但我想从特定问题中恢复，并且我不确定使用未经检查的异常来处理它的最佳方法。这是一个具体的例子。

假设我有一个使用 Struts2 和 Hibernate 构建的 Web 应用程序。如果我的“操作”出现异常，我会将其记录下来，并向用户显示一个漂亮的道歉。但我的 Web 应用程序的功能之一是创建新的用户帐户，这需要唯一的用户名。如果用户选择了一个已经存在的名称，Hibernate 会抛出一个 org.hibernate.exception.ConstraintViolationException （未经检查的异常）在我的系统的内部。我真的很想通过要求用户选择另一个用户名来从这个特定问题中恢复，而不是给他们相同的“我们记录了您的问题，但现在您已经被解决了”消息。

以下是需要考虑的几点：

  1. 有很多人同时创建帐户。我不想在“SELECT”之间锁定整个用户表以查看名称是否存在，如果不存在则锁定“INSERT”。对于关系数据库，可能有一些技巧可以解决这个问题，但我真正感兴趣的是一般情况，由于基本的竞争条件，预先检查异常将不起作用。同样的事情也适用于在文件系统上查找文件等。
  2. 鉴于我的 CTO 通过阅读《Inc.》中的技术专栏而产生了路过式管理的倾向，我需要围绕持久性机制建立一个间接层，以便我可以抛弃 Hibernate 并使用 Kodo 或其他任何东西，而无需更改除最低层之外的任何内容持久化代码层。事实上，我的系统中有几个这样的抽象层。尽管存在未经检查的异常，我怎样才能防止它们泄漏？
  3. 检查异常的声明弱点之一是必须在堆栈上的每次调用中“处理”它们 - 要么声明调用方法抛出它们，要么捕获它们并处理它们。处理它们通常意味着将它们包装在另一个适合抽象级别的类型的检查异常中。因此，例如，在检查异常领域，我的 UserRegistry 的基于文件系统的实现可能会捕获 IOException, ，而数据库实现会捕获 SQLException, ，但两者都会抛出一个 UserNotFoundException 这隐藏了底层的实现。如何利用未经检查的异常，使自己摆脱每一层包装的负担，而不泄漏实现细节？
有帮助吗？

解决方案

IMO，包装异常（检查或其他）有几个值得付出代价的好处：

1）它鼓励您思考您编写的代码的失败模式。基本上，您必须考虑您调用的代码可能抛出的异常，然后您将考虑为调用您的代码抛出的异常。

2) 它使您有机会将额外的调试信息添加到异常链中。例如，如果您有一个方法对重复的用户名引发异常，则可以使用包含有关失败情况的附加信息（例如，提供重复用户名的请求的 IP）的异常来包装该异常，不适用于较低级别的代码。异常的 cookie 跟踪可能会帮助您调试复杂的问题（对我来说当然如此）。

3）它使您能够独立于较低级别代码的实现。如果您正在包装异常并需要将 Hibernate 替换为其他 ORM，则只需更改 Hibernate 处理代码即可。即使底层情况发生了变化，所有其他代码层仍将成功使用包装的异常，并以相同的方式解释它们。请注意，即使 Hibernate 以某种方式发生更改，这也适用（例如：他们在新版本中切换例外）；这不仅仅是为了大规模的技术替代。

4）它鼓励您使用不同类别的异常来代表不同的情况。例如，当用户尝试重用用户名时，您可能会遇到 DuplicateUsernameException；当由于数据库连接损坏而无法检查重复用户名时，您可能会遇到 DatabaseFailureException。反过来，这可以让您以灵活而有力的方式回答您的问题（“我如何恢复？”）。如果您收到 DuplicateUsernameException，您可能会决定向用户建议不同的用户名。如果您收到 DatabaseFailureException，您可以让它冒泡，直至向用户显示“停机维护”页面并向您发送通知电子邮件。一旦有了自定义例外，您就拥有了可自定义的响应——这是一件好事。

其他提示

我喜欢在应用程序的“层”之间重新打包异常，因此例如将特定于数据库的异常重新打包到另一个异常中，这在我的应用程序的上下文中是有意义的（当然，我将原始异常保留为成员，以便我不会破坏堆栈跟踪）。

也就是说，我认为非唯一的用户名并不是一个足够“例外”的情况来保证抛出。我会使用布尔返回参数来代替。由于对您的架构了解不多，我很难说出更具体或适用的内容。

看 用于发电，处理和管理错误的模式

来自分割域和技术错误模式

技术错误绝不应导致域错误产生（吐温绝不应该遇到）。当技术错误必须导致业务处理失败时，应将其包装为Systemerror。

域错误应始终从域问题开始，并由域代码处理。

域错误应通过技术界限“无缝”传递。可能必须序列化和重新确定此类错误才能发生这种错误。代理和外墙应该负责这样做。

技术错误应在应用程序中的特定点上处理，例如边界（请参阅分布边界的日志）。

带有错误的上下文信息的数量将取决于这对后续诊断和处理的有用程度（弄清楚替代策略）。您需要质疑远程计算机的堆栈跟踪是否完全有用（尽管当时错误的代码位置和可变值的代码位置可能有用）

因此，使用未经检查的域异常（例如“UniqueUsernameException”）将休眠异常包装在休眠边界处，并让它一直冒泡到它的处理程序。确保对抛出的异常进行 javadoc，即使它不是受检查的异常！

由于您当前正在使用 hibernate，最简单的事情就是检查该异常并将其包装在自定义异常或您可能在框架中设置的自定义结果对象中。如果您想稍后放弃休眠，只需确保仅将此异常包装在一个位置，即您从休眠中捕获异常的第一个位置，这就是您在进行切换时可能必须更改的代码，因此如果捕获如果在一个地方，那么额外的开销几乎为零。

帮助？

我同意尼克的观点。您描述的异常并不是真正的“意外异常”，因此您应该相应地设计代码，考虑可能的异常。

我还建议您查看 Microsoft Enterprise Library 的文档 异常处理块 它有一个很好的错误处理模式概述。

您可以捕获未经检查的异常，而无需包装它们。例如，以下是有效的 Java。

try {
    throw new IllegalArgumentException();
} catch (Exception e) {
    System.out.println("boom");
}

因此，在您的操作/控制器中，您可以在进行 Hibernate 调用的逻辑周围有一个 try-catch 块。根据异常情况，您可以呈现特定的错误消息。

但我猜今天可能是 Hibernate，明天是 SleepLo​​ngerDuringWinter 框架。在这种情况下，您需要假装拥有自己的小型 ORM 框架来包装第三方框架。这将允许您将任何特定于框架的异常包装成更有意义和/或检查的异常，您知道如何更好地理解这些异常。

  1. 这个问题与检查与检查无关。未经检查的辩论，这同样适用于两种异常类型。

  2. 在抛出 ConstraintViolationException 的点和我们想要通过显示错误消息来处理违规的点之间，堆栈上有大量方法调用，这些方法调用应该立即中止并且不应该关心问题。这使得异常机制成为正确的选择，而不是重新设计从异常到返回值的代码。

  3. 事实上，使用未经检查的异常而不是检查的异常是很自然的选择，因为我们确实希望调用堆栈上的所有中间方法 忽略 例外情况和 不处理它 .

  4. 如果我们只想通过向用户显示一条漂亮的错误消息（错误页面）来处理“唯一名称违规”，则实际上不需要特定的 DuplicateUsernameException。这将使异常类的数量保持较低。相反，我们可以创建一个可以在许多类似场景中重用的 MessageException。

    我们尽快捕获 ConstraintViolationException 并将其转换为带有良好消息的 MessageException。尽快转换它很重要，因为我们可以确定，这确实是“唯一用户名约束”被违反，而不是其他约束。

    在靠近顶级处理程序的地方，只需以不同的方式处理 MessageException 即可。而不是“我们记录了您的问题，但现在您已经被解决了”，只需显示 MessageException 中包含的消息，没有堆栈跟踪。

    MessageException 可以接受一些额外的构造函数参数，例如问题的详细解释、可用的下一步操作（取消、转到不同的页面）、图标（错误、警告）...

代码可能如下所示

// insert the user
try {
   hibernateSession.save(user);
} catch (ConstraintViolationException e) {
   throw new MessageException("Username " + user.getName() + " already exists. Please choose a different name.");
}

在一个完全不同的地方有一个顶级异常处理程序

try {
   ... render the page
} catch (MessageException e) {
   ... render a nice page with the message
} catch (Exception e) {
   ... render "we logged your problem but for now you're hosed" message
}

@简 检查与未检查是这里的一个中心问题。我质疑你的假设（＃3），即在干预框架中应该忽略异常。如果我这样做，我最终将在我的高级代码中得到特定于实现的依赖关系。如果我替换 Hibernate，则必须修改整个应用程序中的 catch 块。然而，与此同时，如果我在较低级别捕获异常，则我不会从使用未经检查的异常中获得太多好处。

另外，这里的场景是我想捕获特定的逻辑错误并通过重新提示用户输入不同的 ID 来更改应用程序的流程。仅仅更改显示的消息是不够的，Servlet 中已经内置了根据异常类型映射到不同消息的功能。

@埃里克森

只是为了给你的想法添加一些食物：

检查与未检查也是 在这里辩论

未经检查的异常的使用符合 IMO 将其用于异常的事实 由函数的调用者引起 （调用者可以位于该函数之上的几层，因此其他框架有必要忽略异常）

关于您的具体问题，您应该在高层捕获未经检查的异常，并将其封装起来，正如 @Kanook 在您自己的异常中所说的那样，而不显示调用堆栈（如 @Jan Soltis 提到的）

话虽这么说，如果底层技术发生变化，这确实会对代码中已经存在的那些 catch() 产生影响，而这并不能回答您的最新情况。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top