design-patterns - 什么情况下应该有人 "try...catch"？这适用于图书馆吗？

Question

假设您正在设计一个应用程序(WebApp、桌面等)并且您需要为代码定义异常处理。既然要让东西可以重用，那么在处理异常的时候应该遵循什么样的逻辑呢？有什么模式可以遵循吗？

例如，如果某些 DLL 将要使用网络并且网络不可靠，那么覆盖该函数的异常处理程序以重试请求可能是明智的。

开发人员如何处理所有常见开发方面的异常？有什么模式或模板可以遵循吗？

在处理诸如网络、文件、IO、Active Directory 和 Web 之类的事情时，我确信有一个关于如何处理当今最常见和最有问题的问题的预设最佳实践。他们位于哪里？

Answer 1

抛出异常自然应该只在异常情况下进行。

对于处理，我会说有两种情况你想捕获异常:

当有翻译要做时

• 错误代码
• 另一个异常(exception)
• 用户可以理解的东西

在模块边界

• 例如从 COM 调用返回(返回到非异常感知框架)
• 从线程返回(否则没有人可以捕获)
• 从回调函数返回(因为回调机制不太可能知道或关心您的异常。)

如果您发现自己在做类似 try-catch-cleanup-rethrow 的事情，请改用 RAII 并完全摆脱 try...catch。编写您的代码，以便在确实发生异常时以理智的方式运行。查看 Abrahams Guarantees 以了解详细信息。

---

下面是对 MakerOfThings7 的回答，因为评论太长了。

“用户可以理解的东西”，我指的是例如弹出式错误消息。

想象一下，如果您愿意的话，用户单击应用程序 UI 上的按钮来检索一些数据。您的按钮单击处理程序会分派(dispatch)到某些数据存储接口(interface)。此接口(interface)可以从内存流、文件和数据库中获取数据。谁知道？反过来，这些可能会失败，生成 MemoryStreamException、FileException 或 DatabaseException。这些可能已向下抛出 15 个堆栈帧，并被编写良好的异常安全代码正确忽略，无需转换它们。

按钮点击处理程序对这些一无所知，因为有越来越多的数据存储方法可供数据存储接口(interface)使用。因此，数据存储接口(interface)会捕获这些异常，并将它们转换 为通用的 DataStorageException。这是抛出的。

然后，调用数据存储接口(interface)的按钮单击处理程序捕获此异常，并有足够的信息能够向用户显示某种失败消息，将异常转换为一些很好的格式化文本并呈现它。