如果我这么做，就会得到一个System.StackOverflowException异常：
private string abc = "";
public string Abc
{
get
{
return Abc; // Note the mistaken capitalization
}
}
我理解这个问题的原因是该属性引用了它自己，导致无限循环（请参见之前的问题这里和这里）。
但我想知道的是（之前的问题中没有回答），为什么C#编译器没有捕获到这个错误呢？编译器会检查其他一些循环引用的情况（如类从自身继承等），对吗？难道只是这个错误不常见，不值得检查吗？或者有没有我没有考虑到的情况，需要让属性实际上以这种方式引用自己？
除了Alex的解释之外，另一个要点是我们试图对那些可能会做出你并不想要的操作的代码发出警告，这样你就不会意外地发布带有错误的代码。
在这种情况下，警告实际上能够节省多少时间？仅是一次测试运行。你会在测试代码时立即发现这个错误，因为它会立即崩溃并死亡。在这里，警告实际上无法给你带来太多的好处。递归属性评估中存在一些微妙错误的可能性很低。
相比之下，如果你像这样做某些事情，我们确实会发出警告：
int customerId;
...
this.customerId= this.customerId;
这段代码不会导致程序崩溃，且是有效的代码；它将一个值分配给了一个字段。但由于这是一段毫无意义的代码，你可能并不想这样做。由于它不会导致程序崩溃，我们会发出警告，提示你可能没有意识到这里有些东西，并且可能无法通过程序崩溃来发现。
StackOverflowException突然出现的位置可能会被卡住几分钟。一个简单的警告可以在这种情况下为许多开发人员节省宝贵的时间，这很容易检测，并且几乎肯定是一个错误。 - MgSam引用自身的属性并不总是导致无限递归和堆栈溢出。例如，以下代码可以正常工作：
int count = 0;
public string Abc
{
count++;
if (count < 1) return Abc;
return "Foo";
}
以上是一个虚拟的例子，但我相信人们可以想出类似的有用的递归代码。编译器无法确定是否会发生无限递归（停机问题）。
在简单情况下生成警告将是有帮助的。
他们可能认为这样做会使编译器变得不必要的复杂，而没有任何真正的收益。
第一次调用此属性时，您很容易发现这个拼写错误。
首先，你会收到一个未使用变量abc的警告。
其次，递归本身并没有什么不好的，只要它不是无限递归。例如，代码可能会调整一些内部变量，然后递归调用相同的getter。然而，对于编译器来说，很难证明某些递归是无限的还是有限的（这至少是一个NP问题）。编译器可以捕捉一些简单的情况，但是消费者会感到惊讶，因为更复杂的情况能够通过编译器的检查。
它检查的其他情况（除了递归构造函数）都是无效的IL。
此外，所有这些情况，即使是递归构造函数，也保证会失败。
然而，有可能（虽然不太可能）有意创建一个有用的递归属性（使用if语句）。