当并非所有代码路径都返回时,C#编译器不会抱怨

pus*_*kin 3 c# using compiler-errors

我有一个在using块中返回的函数:

int f() {
  using (...) {
     ...
     return someVar;
  }
}
Run Code Online (Sandbox Code Playgroud)

我刚注意到这一点,并将块的return外部移动using到最外层的功能范围,因为我觉得这return应该是应该的.

但我很困惑为什么编译器没抱怨并非所有代码路径都返回.这只是因为如果它无法初始化资源,我们会崩溃,所以没关系?

举个例子:

class MainClass {
  public static void Main (string[] args) {
    f();
  }

  public static int f() {
    using(A a = new A()) {
      return 1;
    }
  }
}

class A : IDisposable{
  public void Dispose() { }
}
Run Code Online (Sandbox Code Playgroud)

编译器并不关心我们只返回using.但是,我认为using陈述基本上是语法糖try/catch

如果我们更换

using(A a = new A()) {
  return 1;
}
Run Code Online (Sandbox Code Playgroud)

A a = new A();;
try  {
  return 1;
}

catch (Exception e) { }
finally {
  if (a != null) {
    ((IDisposable) a).Dispose();
  }
}
Run Code Online (Sandbox Code Playgroud)

确实,编译器抱怨:

错误CS0161:`MainClass.f()':并非所有代码路径都返回一个值

为什么不在其他情况下抱怨?

这只是我上面所说的吗?如果它无法初始化资源,我们会崩溃,因此编译器决定它无关紧要.

Wil*_*sem 5

实际上:

using(var objectName = <init-expression>) {
    //...
}
Run Code Online (Sandbox Code Playgroud)

或多或少相当于:

objectName = <init-expression>;
try {
    //...
} finally {
    objectName.Dispose();
}
Run Code Online (Sandbox Code Playgroud)

所以这是一个try- finally-阻塞:如果在执行过程中出现错误,异常会被抛出的方法(主要是后finally部分已经完成).

A try- finally但是不会创建替代代码路径:如果try-part返回某些内容或抛出错误,它将首先执行finally-part,然后抛出异常或返回应该返回的内容.