我目前正在编写我的第一个 Windows 窗体应用程序。我现在已经阅读了几本 C# 书籍，因此对 C# 必须处理异常的语言特性有了相对较好的了解。然而，它们都非常理论化，因此我还没有了解如何将基本概念转化为应用程序中良好的异常处理模型。
有人愿意分享关于这个主题的智慧吗？发布您见过像我这样的新手所犯的任何常见错误，以及有关处理异常的任何一般建议，以使我的应用程序更加稳定和健壮。
我目前正在努力解决的主要问题是：
- 我什么时候应该重新抛出异常？
- 我应该尝试拥有某种中央错误处理机制吗？
- 与先发制人地测试磁盘上的文件是否存在等事情相比，处理可能引发的异常是否会对性能产生影响？
- 所有可执行代码都应该包含在 try-catch-finally 块中吗？
- 是否有任何时候可以接受空的 catch 块？
非常感谢所有建议！
还有几位...
您绝对应该制定集中的异常处理策略。这可以像包装一样简单Main()在 try/catch 中，快速失败并向用户发送一条优雅的错误消息。这是“最后的手段”异常处理程序。
如果可行的话，先发制人的检查总是正确的，但并不总是完美的。例如，在检查文件是否存在的代码与打开文件的下一行之间，该文件可能已被删除，或者某些其他问题可能会阻碍您的访问。在那个世界里你仍然需要 try/catch/finally 。根据需要使用抢先检查和 try/catch/finally。
永远不要“吞掉”异常，除非在最有据可查的情况下，当您绝对、肯定地确定抛出的异常是可以接受的时。这种情况几乎永远不会发生。 （如果是的话，确保你只吞下specific异常类——不ever吞System.Exception.)
构建库（由您的应用程序使用）时，不要吞下异常，也不要害怕让异常冒泡。除非您有一些有用的东西要添加，否则不要重新抛出。永远不要（在 C# 中）这样做：
throw ex;
因为您将擦除调用堆栈。如果必须重新抛出（有时是必要的，例如使用企业库的异常处理块时），请使用以下内容：
throw;
归根结底，正在运行的应用程序抛出的绝大多数异常都应该在某个地方公开。它们不应该暴露给最终用户（因为它们通常包含专有或其他有价值的数据），但通常会被记录下来，并向管理员通知异常情况。可以向用户呈现一个通用对话框，可能带有参考号，以使事情简单。
.NET 中的异常处理与其说是科学，不如说是艺术。每个人都会在这里分享自己的最爱。这些只是我从第一天开始使用 .NET 时所学到的一些技巧，这些技巧曾多次挽救了我的困境。你的旅费可能会改变。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
