C# Return和finally子句-不一致行为

我遇到了有点奇怪（IMO）的代码，它的行为不一致

try
{
   if (helperMethod())
   {
       return 0;
   }

   return 0;
 }
 catch(Exception e)
 {
    // Log and throw
 }
 finally
 {
     // Do a lot of stuff after value has been returned
 }

它位于一个方法中，VBA通过将COM对象传递到我的DLL来调用该方法。当它刚刚运行时，我在C#中没有得到异常，但我得到了一个VBA异常

当我在调试中运行它时，我不会在任何地方出现异常

我的猜测是finally子句中的逻辑需要一秒钟的时间来运行，此时方法的主体已经返回了0

我可以用几种方式重新编写，但我不知道以这种方式编写代码是否常见

多谢各位

---

编辑：当我返回0时，是否会释放COM对象？在这种情况下，finally子句中不再提供它

我认为您可能正在尝试（无意使用双关语）以一种奇怪的方式使用finally块。框架文件的最终代表性如下：

finally块用于清理try块中分配的任何资源

---

您应该在try块内完成工作（或者在try-catch-finally构造之外，如果它只是覆盖一个潜在的异常条件，而不是返回数据的后续处理）并且您的finally块应该只释放在try中分配的任何需要释放的资源，而不考虑异常或正常终止。

COMException可能会使您的.NET CLR引擎崩溃，从而使引擎没有机会运行finally代码。在这些情况下，您将在事件日志中看到一个条目

---

我在WMI上见过很多这样的东西。邪恶，邪恶…

finally块中的所有代码都将在该函数返回之前执行。您好，谢谢。您的意思是它将返回station、pause、执行finally子句中的所有内容，然后继续返回吗？是的，return语句建立返回值，但函数通过finally块退出。如果有帮助，请想象

返回0

实际上是

返回一些函数，它本身返回sanint（）-在这种情况下，将发生以下情况：1）运行其自身返回的某个函数int

，并将其返回的值“存储”2）最后运行

中的代码3）将返回（1）中存储的值，作为所有有意义的方法的结果，我将花更长的时间来研究这个问题，以找出代码在调试模式下（有时）成功执行的原因。我完全同意你的看法。这不是我的代码和逻辑，我不喜欢自己的代码和逻辑。我需要了解COM对象是否在某些逻辑上被释放，是否执行得太早，或者根本没有执行。我想我的观点是，你不应该花太多时间试图弄清这个论点的底细，而应该花时间重写代码，让自己进入一个清晰可预测的源代码（也可以预测任何执行路径）.问题确实出在逻辑上，必须重新编写，现在一切都正常了。Thanks@Henk霍特曼：我意识到我没有回答他的具体问题，但这里似乎有一个边缘案例。很容易被错误缠住，忽略了代码气味难闻这一点。应该首先解决代码气味，如果没有其他东西的话，如果还没有消除实际的bug，它会使查找实际bug变得更容易。在EventLog中输入，你是指EventViewer吗？如果不是，那么我在哪里可以找到它？谢谢你的回复，但这已经解决了。我必须重新编写整个方法。