问题标签 [exception-handling]

发生在数据访问层甚至更高层深处的错误（例如在 ADO.net 操作中）对最终用户来说几乎没有多大意义。简单地将这些错误冒泡到 UI 并显示它们通常只会让最终用户感到沮丧。

我最近采用了一种基本技术来报告诸如此类的错误，借此我可以捕获错误并至少添加一些用户友好的文本，以便至少最终用户了解失败的原因。

为此，我在每个特定函数中捕获异常（例如，数据访问层中的获取函数），然后使用用户友好的文本引发一个新错误，该错误是关于失败并可能导致的函数，然后嵌入原始新异常中的异常作为该新异常的“内部异常”。

如有必要，这可以在每一层发生，每个低层函数的消费者都将它自己的上下文添加到错误消息中，这样到达 UI 的就是越来越用户友好的错误消息。

一旦错误到达 UI - 如果有必要 - 它可以遍历嵌套的异常，以显示错误消息，首先告诉用户哪个操作失败，但也提供一些关于实际错误的技术信息。

例如

“您请求的客户名称列表无法显示。”

“由于数据库错误，获取您请求的客户列表失败。”

“检索客户列表时连接到数据库时出错”

“用户 xx 登录失败”

我的问题是：这是否非常低效（所有这些嵌套异常）？我怀疑这不是最佳实践，所以我应该怎么做才能实现同样的目标 - 或者我实际上应该尝试实现更好的目标？

基本上我听说某些条件会导致 .net 吹过 finally 块。有谁知道这些条件是什么？

I've seen the following code many times:

Can you please explain the purpose of re-throwing an exception? Is it following a pattern/best practice in exception handling? (I've read somewhere that it's called "Caller Inform" pattern?)

在析构函数中，有没有办法确定当前是否正在处理异常？

这是一个暴露我缺乏经验的问题：我有一个方法DoSomething()如果它不能干净地完成它，它会抛出异常。如果失败了，我会多次尝试不太准确的方法DoSomethingApproximately() ，希望它能找到足够好的解决方案；如果这也失败了，我最后打电话给DoSomethingInaccurateButGuaranteedToWork()。这三个都是属于这个对象的方法。

两个问题：首先，这种（诚然丑陋的）模式是否可以接受，还是有更优雅的方式？

其次，考虑到它可能引发异常，跟踪我调用DoSomethingApproximately()多少次的最佳方法是什么？我目前在对象中保留一个变量 iNoOfAttempts，并嵌套 try 块......这太可怕了，我很惭愧。

我见过有人说不带参数使用 catch 是不好的形式，特别是如果那个 catch 没有做任何事情：

但是，这被认为是好的形式：

据我所知，将清理代码放在 finally 块中和将清理代码放在 try..catch 块之后的唯一区别是，如果你的 try 块中有 return 语句（在这种情况下，finally 中的清理代码将运行，但 try..catch 之后的代码不会）。

不然最后有什么特别的？

我们正在审查该公司的一个系统的异常处理，并发现了一些有趣的事情。

大多数代码块（如果不是全部）都在 try/catch 块内，并且在 catch 块内抛出了一个新的 BaseApplicationException - 这似乎来自企业库。我在这里有点麻烦，因为我看不到这样做的好处。（任何时候发生异常都会抛出另一个异常）其中一位已经使用该系统一段时间的开发人员说这是因为该类负责发布异常（发送电子邮件和类似的东西），但他不太确定。在花了一些时间浏览代码之后，我很有信心地说，它所做的就是收集有关环境的信息，而不是发布它。

我的问题是： - 将所有代码包装在 try { } catch { } 块中而不是抛出新异常是否合理？如果是，为什么？有什么好处？

我个人的看法是，使用 HttpModule，注册 Application 事件的 Error 事件，并在模块内做必要的事情会容易得多。如果我们沿着这条路走，我们会错过什么吗？有什么缺点吗？

非常感谢您的意见。

我一直觉得期望定期抛出异常并将它们用作流逻辑是一件坏事。异常感觉它们应该是“异常”。如果您期望并计划出现异常，那似乎表明您的代码应该被重构，至少在 .NET 中......
但是。最近的一个场景让我停下来。不久前我在 msdn 上发布了这个，但我想引起更多关于它的讨论，这是一个完美的地方！

因此，假设您有一个数据库表，其中有几个其他表的外键（在最初引发辩论的情况下，有 4 个外键指向它）。您希望允许用户删除，但前提是没有外键引用；你不想级联删除。
我通常只是检查是否有任何引用，如果有，我会通知用户而不是删除。在 LINQ 中编写它非常容易和轻松，因为相关表是对象上的成员，因此 Section.Projects 和 Section.Categories 等很适合用智能感知和所有类型输入......
但事实是 LINQ 然后必须可能会访问所有 4 个表以查看是否有任何结果行指向该记录，并且访问数据库显然总是一个相对昂贵的操作。

该项目的负责人要求我将其更改为仅捕获代码为 547（外键约束）的 SqlException 并以这种方式处理它。

我是……
抗拒的。

但是在这种情况下，吞下与异常相关的开销可能比吞下 4 个表命中要有效得多……尤其是因为我们必须在每种情况下都进行检查，但我们可以避免这种情况下的异常当没有孩子时...
加上数据库确实应该负责处理引用完整性，这是它的工作并且做得很好...
所以他们赢了，我改变了它。

但在某种程度上，我仍然觉得它是错误的。

你们如何看待期待和有意处理异常？当它看起来比事先检查更有效率时可以吗？下一个查看您的代码的开发人员是否更容易混淆，或者更容易混淆？是否更安全，因为数据库可能知道开发人员可能不会考虑添加检查的新外键约束？还是你认为最佳实践的观点是什么？

我有一个if条件来检查值并抛出新的NumberFormatException

有没有其他方法来编码这个

本文很好地概述了为什么结构化异常处理不好。有没有办法获得阻止服务器崩溃的稳健性，同时克服文章中提到的问题？

我有一个服务器软件，可以同时运行大约 400 个连接的用户。但如果发生崩溃，所有 400 个用户都会受到影响。我们添加了结构化异常处理并享受了一段时间的结果，但最终不得不将其删除，因为一些崩溃导致整个服务器挂起（这比让它崩溃并自行重启更糟糕）。

所以我们有这个：

• 使用 SEH：400 中只有 1 个用户在大多数崩溃中遇到问题
• 没有 SEH：如果任何用户发生崩溃，所有 400 都会受到影响。
• 但有时与 SEH：服务器挂起，所有 400 都受到影响，未来的用户会尝试连接。