库中的exception处理策略
构建.NET库时，您的exception处理策略是什么？ 具体来说，您在处理库调用中的exception并将它们暴露给调用代码的策略是什么？
例如，
- 您是否将库函数视为任何其他函数，从而让它无法处理的所有exception都按原样流出？
- 您会为该库创建自定义例外吗？
- 你会捕获所有exception并抛出库的exception吗？ 您是否将原始exception设置为库的exception内部exception？
- 库对数据库的依赖会如何影响您的exception处理策略？
您建议在.NET库中进行exception处理的准则和规则是什么？
您是否将库函数视为任何其他函数，从而让它无法处理的所有exception都按原样流出？
是的，这绝对是默认策略。
您会为该库创建自定义例外吗？
是的，如果呼叫者可以想象对此情况采取某些措施并且这样做，他们需要能够将exception与其他exception区分开来。 但这种情况非常罕见。
库对数据库的依赖会如何影响您的exception处理策略？
数据库依赖关系可能需要公开允许调用者指定库如何处理某些exception的设置（例如， MaximumDeadlockRetries ）。
你会捕获所有exception并抛出库的exception吗？ 您是否将原始exception设置为库的exception内部exception？
不，不是所有例外。 对于特定的例外，它是远程可能的，尽管我能想到的唯一情况是我的库可能已经尝试处理exception（如上面的数据库场景中）并且失败了。
- 我让所有exception泡沫我认为用户可以处理。 这基本上是我认为他应该看到的东西（IO等）
- 我用更抽象的方式包装了我想要重新抛出的所有例子。 在O / R映射器中，我有一个“DataAccessException”，它在内部得到任何SQLexception – 因此用户不必处理它们的内在函数。 这里的想法是，任何应用程序可能想要知道发生的SQL级别exception，但无论如何都无法尝试修复它（感谢数据库是众多类型之一等） – 所以包装器是好的。
- 我从不使用generics捕获所有调试之外的东西。
- 我总是有一个顶级处理程序（appdomain级别 – 未处理的exception事件）来尝试向用户显示发生意外的exception并将其提交给支持。
自定义exception – 当它们有意义时。 由于框架中的一些通用exception，情况并非如此。
包含可能抛出不同exception的几个不同类的库应该允许IMHO不允许来自内部的exception作为其原始类型渗透。 相反，它们应该包含在特定于库的exception中，尽可能清楚地与exception的原始类型相关。
例如，MagicDatabaseLibrary可能定义MagicDatabaseException，后者又有一些派生exceptionMagicDatabaseTimeoutException，MagicDatabaseAuthenticationException等。如果SQL Server数据库抛出SQL Server超时exception（无论它被调用），那么应该包含在MagicDatabaseTimeoutException中。 同样，对于可能发生的任何其他半预期exception。
如果没有这样做，那么调用库的代码将没有实际的选择，但如果它有希望处理潜在的数据库问题，则使用“Pokemonexception处理”。 例如，如果调用代码应该处理用户提供凭据以登录数据库并且连接失败的情况，则需要能够捕获该exception。 如果调用代码不知道将会是什么类型的exception，除了捕获每个exception之外它没有什么可做的，希望它是由不正确的凭据或其他东西引起的，并向用户显示一条消息，说连接失败。 不像提供包装exception那样有用。