通常情况下使用System.Exception并不被推荐,但我想知道这是不是我的唯一选择。
我的场景如下:
1. 用户请求编辑任务。 2. 进行权限检查。 3. 如果一切正常,从数据库中检索到任务行。 4. 然后提交任务更新,并更新列以表示它已被锁定。 5. 对此任务应用一些时区处理,将日期转换为本地时间。 6. 将任务显示给用户。
因此,如果在步骤1到4之间发生任何事情,该任务仍然是良好的,因为它没有被锁定。但是,如果在第5步失败并且我无法向用户显示任务,则文件将被锁定,并且将一直保持锁定状态,直到计划作业运行以确保长时间锁定的文件被强制解锁。
这种情况并不理想,因为它可能只是暂时故障,下次请求文件时可能会再次工作。但现在他们必须等待(所有其他订阅者也是如此)X分钟才能自动解锁。
所以我的第一个想法是使用finally语句,但是这总是被运行,无论发生什么情况,所以我无法想出如何说文件现在已被锁定,请勿尝试解锁它。
或者文件已被锁定,但发生了错误,请解锁它。如果C#有一种仅在发生异常时运行的语句,那就太好了。
所以我唯一的其他想法是使用一个异常,如果发生任何事情,它将在其中解锁它。唯一不解锁的情况是如果出现SQl异常,因为如果数据库关闭,则没有尝试解锁任何内容。
当然,我会使用elmah记录错误,并随着发生的更好的异常类型而慢慢添加它们。
那么,有人有更好的想法吗?
我的场景如下:
1. 用户请求编辑任务。 2. 进行权限检查。 3. 如果一切正常,从数据库中检索到任务行。 4. 然后提交任务更新,并更新列以表示它已被锁定。 5. 对此任务应用一些时区处理,将日期转换为本地时间。 6. 将任务显示给用户。
因此,如果在步骤1到4之间发生任何事情,该任务仍然是良好的,因为它没有被锁定。但是,如果在第5步失败并且我无法向用户显示任务,则文件将被锁定,并且将一直保持锁定状态,直到计划作业运行以确保长时间锁定的文件被强制解锁。
这种情况并不理想,因为它可能只是暂时故障,下次请求文件时可能会再次工作。但现在他们必须等待(所有其他订阅者也是如此)X分钟才能自动解锁。
所以我的第一个想法是使用finally语句,但是这总是被运行,无论发生什么情况,所以我无法想出如何说文件现在已被锁定,请勿尝试解锁它。
或者文件已被锁定,但发生了错误,请解锁它。如果C#有一种仅在发生异常时运行的语句,那就太好了。
所以我唯一的其他想法是使用一个异常,如果发生任何事情,它将在其中解锁它。唯一不解锁的情况是如果出现SQl异常,因为如果数据库关闭,则没有尝试解锁任何内容。
当然,我会使用elmah记录错误,并随着发生的更好的异常类型而慢慢添加它们。
那么,有人有更好的想法吗?
System.Exception
。 - Marc