.net - .Net:尝试…捕捉偏执狂-它在哪里结束？

Question

我想我有类似“程序员的OCD”的东西。我希望自己的代码既美观又简洁，并且希望它“完美”(例如正确正确地处理所有可能的情况)。我经常发现自己花费大量时间一次又一次地遍历相同的领域，以查看可以在哪些方面进行优化以及在哪些方面可以做到万无一失。

因此，当尝试使用...捕获块时，我对封装内容有些偏执。我的意思是，我应该在哪里划清代码应满足的条件？以文件处理为例。我是否应该将每个该死的文件操作放在try ... catch块中，以防万一可能发生(文件被应用程序外部的某人/某物锁定，磁盘损坏等)？

有时，它使我感到不安，可能是有些东西(我什至不知道)可能会使某些代码崩溃。

编辑:

我不是在谈论使用try ... catch涵盖糟糕的编程，而是在谈论本来可以正确实现的操作和过程，但是要依靠我无法控制的其他因素-即使它们可能是晦涩(这就是重点)，并且只会在我没有预料到的极其“不幸”的情况下发生。

文件处理就是一个明显的例子。当我倾向于抖动时，就是想知道内置功能的幕后将进行什么样的处理，以及它如何响应我的代码。

这是一个例子:

Dim serverUrl as String = My.Settings.ServerUrl

那里涉及磁盘操作(从app.config中读取)。应该将其包含在try ... catch块中吗？这就是我在哪里结束的意思。

担心内存泄漏是另一回事。难道只有不受管理的代码才构成威胁吗？我怎么知道什么是非托管代码？有清单吗？

更多编辑:

我不确定的另一个领域是在引擎盖下某个地方存在访问限制或策略。

当我阅读有关编程的文章和讨论时，会看到很多类似的解释，“嗯，您的问题是，当您调用X时，.Net在内部尝试某某某类访问，除非您应用程序在上下文类型Y中运行，或者您具有特权Z，它将引发异常”。这只是增加了我的偏执-当涉及到构建水密异常处理时。因为我只是不了解语言/平台的所有内部功能，也不知道在哪里看(而不必花我的时间去研究它)。

我很乐意为此提供某种形式的纲要或简明Wiki，它将概述需要特别关注的编程领域(文件处理等)，以及示例方案，典型挑战和元凶(包括解决方案)，最佳实践模型，编程模式，并且至少为像我这样的凡人提供了一组准则，不幸的是，它们实际上并未参与构建语言及其库。

所有这些都集中在一个地方，而不必在语言参考资料或网络上的随机文章中查找分散的信息-在许多情况下，我什至不知道要寻找什么。

对于我当前的特定项目，它在Windows Service的上下文中。没有UI，我正在处理的子任务之一就是创建一个健壮的引导程序，该引导程序可以妥善处理所有问题情况。在这种情况下，这全都与记录有关-然后忽略该异常(如果足够琐碎的话)-或直接退出!如果尝试登录时发生问题-我该怎么办？只是退出-找不到发生的一切？该引导程序仅记录其启动情况(此后，动态加载的主程序集将接管并记录其自身的内容，尽管面临相同的挑战)，并将其记录到简单的“bootstrap.log”文件中。将其记录到EventLog会更好(或值得一提)吗？还是EventLog是另一个可能引发新问题的领域(再次出现访问限制等。EventLog是否也基于需要“尝试并捕获”的磁盘操作？)？

看到？偏执狂。

Answer 1

我是否应该将每个该死的文件操作放在try ... catch块中，以防万一可能发生(文件被应用程序外部的某人/某物锁定，磁盘损坏等)？

通常，是的。

必须处理的异常

文件操作本质上是不安全的，使用时可能会崩溃。考虑以下情况:您正在读取存储在USB存储设备上的文件，并且在读取过程中用户拔出了USB记忆棒。

这将引发异常，您需要提防该异常。在您提到的特定示例中也是如此。

另一方面，通常只有高层代码需要处理这种错误，而不是业务逻辑中深处的代码。通常可以让方法失败并传播由于IO故障而导致的异常。只是重要的是要防止该异常导致应用程序崩溃，并通知用户出了点问题，或者重试，或者采取规避措施。

哪些层处理异常？

An article from 2003 by Ned Batchelder解释了代码的哪些部分应防止出现异常，而哪些则不应:

他将代码分为三层:

A层和，以适应其下的API

B层，系统的 b 组件和

C层， c 组合在一起。

我会选择略有不同的图层:

底层层(由A层和B层组成)构成了系统的底层API并适应甚至底层的API)，

实现大部分业务逻辑的中间层(主要是B和C层)和

用户与之交互的UI层。

无论如何，最低层 都应将较低层API的异常转换为您的域。

中间层应该让异常通过传递:业务层中没有异常处理。这也应该是代码的大部分内容，这意味着您不需要处理大多数代码中的异常(但是此规则当然可能会有异常)。

上层 应该捕获异常并对其进行响应，或者以可读格式将其呈现给用户。
处理此类异常的一种好方法是安装全局异常处理程序，或将GUI应用程序中的工作分流到额外的线程(例如BackgroundWorker)中，并在线程死后捕获异常。

异常无法处理

并非所有异常都需要以这种方式处理。例如，您不应该尝试处理 StackOverflowException(您不能!)或 OutOfMemoryException(您通常不能)。

这样的异常意味着代码或机器都存在严重问题，并且您的应用程序没有机会从故障中恢复。