在这种情况下使用System.Exception是否合适？

Question

通常情况下使用System.Exception并不被推荐，但我想知道这是不是我的唯一选择。

我的场景如下：

1. 用户请求编辑任务。 2. 进行权限检查。 3. 如果一切正常，从数据库中检索到任务行。 4. 然后提交任务更新，并更新列以表示它已被锁定。 5. 对此任务应用一些时区处理，将日期转换为本地时间。 6. 将任务显示给用户。

因此，如果在步骤1到4之间发生任何事情，该任务仍然是良好的，因为它没有被锁定。但是，如果在第5步失败并且我无法向用户显示任务，则文件将被锁定，并且将一直保持锁定状态，直到计划作业运行以确保长时间锁定的文件被强制解锁。

这种情况并不理想，因为它可能只是暂时故障，下次请求文件时可能会再次工作。但现在他们必须等待（所有其他订阅者也是如此）X分钟才能自动解锁。

所以我的第一个想法是使用finally语句，但是这总是被运行，无论发生什么情况，所以我无法想出如何说文件现在已被锁定，请勿尝试解锁它。

或者文件已被锁定，但发生了错误，请解锁它。如果C#有一种仅在发生异常时运行的语句，那就太好了。

所以我唯一的其他想法是使用一个异常，如果发生任何事情，它将在其中解锁它。唯一不解锁的情况是如果出现SQl异常，因为如果数据库关闭，则没有尝试解锁任何内容。

当然，我会使用elmah记录错误，并随着发生的更好的异常类型而慢慢添加它们。

那么，有人有更好的想法吗？

- chobo2

---

自从什么时候开始不赞成使用异常了？ - Jean-Bernard Pellerin

在我看来，让异常驱动你的逻辑是不被赞同的。 - Marc

@ Jean-Bernard Pellerin - 使用异常并不会被看作是不好的做法，但是如果仅仅为了所有情况都使用“Exception()”，那么就会被人所不齿。 - chobo2

@Marc - 我并不认为它驱动我的逻辑，它只是可能发生的一个结果，我应该为此做好准备。如果你有更好的方法来避免将它包装在通用异常中，那我很乐意听取建议并采用。 - chobo2

@chobo2，我明白了，我最初理解成“例外”，而不是System.Exception。 - Marc

C#确实有一个声明仅在异常情况下运行的代码结构->catch{}。然而，它的使用是有争议的。 - Rune FS

Answer 1

不要让完美成为好的敌人。在这种情况下，捕获一般异常是完全可以的。如果您能够捕获并从更具体的异常类型中恢复，请这样做。但是，拥有一个“一切都崩溃了”的恢复计划不仅可以接受，而且值得赞扬。

- Chris Van Opstal

Answer 2

如果它是线程的顶部，且您不希望程序在任何情况下崩溃，那么捕获System.Exception是可以接受的。一般来说，捕获System.Exception是一个坏主意，因为您应该对可能发生的错误类型有一些了解，这样当发生完全意外的情况时，它会冒泡到您的线程的顶部，在那里您可以捕获System.Exception并可能提供堆栈跟踪信息等以进行调试。

在您的情况下，由于您担心在处理时区转换的步骤5中可能会发生“糟糕的事情”，因此您可以尝试预测可能触发那里的特定异常或异常类，并具体捕获这些异常，适当处理解锁。

或者，由于您显然有能力创建查找已锁定文件并有效地强制解锁的计划任务，所以您不能在finally块中使用相同的逻辑吗？例如，如果被锁定，则解锁它，否则不执行任何操作。

- danielpops