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

Question

通常它不喜欢使用System.Exception，但我想知道这是否是我唯一的选择。

我有这样的情况下编辑

权限检查完成

1. 用户请求的任务。
2. 如果全部都是良好的db任务行检索
3. 然后提交该任务的更新并更新列以表明它已被锁定。
4. 一些时区的东西被应用到这个任务将日期转换为本地时间。
5. 任务显示给用户。

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

这种情况并不理想，因为它可能会暂时失败，下一次他们请求文件时可能会再次运行。但是现在他们必须等待（与所有其他订户相同）X分钟，直到它自动解锁。

因此，我的第一个想法是使用最后的声明，但无论如何，这总是得到运行，所以我无法弄清楚如何说好文件现在被锁定，不要打开它解锁。

或者该文件被锁定，但出现问题解锁它。如果C＃有一个只在发生异常时才运行的语句，那将会很好。

所以我唯一的想法是有一个异常，如果发生任何事情，它会在那里解锁它。唯一的情况是，如果它是一个SQl异常，因为如果数据库关闭，没有任何一点试图解锁某些东西。

当然，我会用elmah来记录错误并缓慢地添加更好的异常类型，因为它们会发生。

那么有没有人有更好的想法？

Answer 1

不要让完美成为好的敌人。在这种情况下捕捉一般异常是非常好的。如果您可以捕获并从更具体的异常类型中恢复，请执行此操作。但拥有一切即将到来的地狱恢复计划不仅可以，而且值得称赞。

Answer 2

捕捉System.Exception是可以接受的，如果它是一个线程的顶部，并且你不希望你的程序在任何情况下崩溃。一般来说，捕捉System.Exception是一个坏主意，因为您应该对可能发生的错误有一些了解，例如当发生完全意想不到的事情时，它会冒泡到您的线程的顶部，在那里捕获System.Exception并可能提供堆栈跟踪信息等用于调试目的。在你的情况中，由于你担心在处理时区转换的第5步中发生的“不好的事情”，你可以尝试预测哪些特定的异常或异常类可能会在那里触发，特别是捕捉它们，处理适当解锁。

另外，因为你显然有能力创建所述计划的任务，其中发现锁定的文件，并有效地强制解锁，你不能在你的finally块中使用相同的逻辑吗？例如如果它被锁定，解锁它，否则，noop。