Csharp 使用TryCatchFinally为API端点处理代码有什么缺点

发布于11月15日

我知道这是一个糟糕的设计，我正在努力寻找任何不这样做的理由，所以我需要一些帮助.

我有一个正在命中的API端点，需要在最多几秒钟内返回OK响应.目前，我们正在进行调用并处理大量数据，然后返回OK，但是，如果DoLotsOfWork方法超时，则不会返回OK响应.

public IActionResult DoWork([FromBody] MyDTO myDto){
     DoLotsOfWork();
    return OK()
}

现在我建议我们迁移到某种类型的队列，让作业(job)在那里运行，但我被拒绝了，因为这项工作将花费很长时间.相反，我被告知要这么做.

public IActionResult DoWork([FromBody] MyDTO myDto){
   try{
       return OK();
   }
   catch{
   }
   finally{
      DoLotsOfWork();
   }  
}

有人知道这样做有什么缺点吗？

推荐答案

因为实际的问题看起来完全是"有什么缺点？"，而且您似乎知道try-catch-finally是如何工作的，作为一种在API响应后执行代码的方式(尽管在 comments 和答案中有些人解释了它的作用)，我只会链接到Stephen Cleary编写的this very well-written StackOverflow answer to a similar question.

Edit 2: vatbub's answer below用这种方法列出的问题在#4中提出了一个很好的观点(1-3基本上重申了try-catch个误用)，下面的描述详细说明.

Edit:以防它从互联网上消失:

我需要"开火然后忘却"

我有一篇博客文章，详细介绍了几种不同的接近fire-and-forget on ASP.NET美元.

总而言之:首先，试着根本不做一劳永逸的事情.就快到了一直都是个坏主意.你真的想"忘记"吗？就像在，不关心它是否成功地完成了？是否忽略任何错误？接受偶尔在没有任何日志(log)通知的情况下"丢失工作"？几乎总是，答案是否定的，"一发不可收拾"不是合适的方法.

可靠的解决方案是构建适当的分布式体系 struct . 也就是说，构造一个表示要完成的工作的消息，并将该消息排队到可靠队列(例如，Azure队列、MSMQ等). 然后具有处理该队列的独立后端(例如，Azure 网络作业(job)、Win32服务等).

我应该只调用Task.Run()而不使用任何task-await吗？

不是的.这可能是最糟糕的解决方案.如果你必须这样做然后忘记，你不愿意构建一个分布式的建筑，然后考虑Hangfire.如果这对你不起作用，那么至少你应该登记你的牛仔背景工作使用ASP.NET运行时(通过 HostingEnvironment.QueueBackgroundWorkItem或者我的ASP.NET Background Tasks library.请注意，QBWI和AspNetBackEarth Tasks都是不可靠的解决方案；它们只会将您失败的可能性降至最低工作，而不是阻止它.