C＃编译器在每次编译时不会立即报告所有错误吗？

Question

当我编译这个项目时，它在错误列表窗口中显示400多个错误，然后我转到错误站点，修复一些，然后数字说120+错误，然后在修复一些之后，下一个编译报告再次像400+。 我可以看到错误列表窗口中出现了不同的文件，所以我认为编译器在发生一定数量的错误后会中止？

如果是这样，原因是什么？ 它是否应该收集项目中存在的所有错误，即使它们超过10K +？

Answer 1

我一直想写一篇关于此的博客文章。

对于报告的错误数量，您可能只是遇到了一些硬编码限制。 你也可能遇到一个更微妙和有趣的场景。

命令行编译器和IDE编译器中有许多试图管理错误报告的启发式方法。 两者都是为了让用户可以管理，并使编译器更加健壮。

简而言之，编译器的工作方式是尝试通过一系列阶段获取程序，您可以在这里阅读：

http://blogs.msdn.com/b/ericlippert/archive/2010/02/04/how-many-passes.aspx

我们的想法是，如果早期阶段出现错误，我们可能无法在没有（1）进入无限循环，（2）崩溃或（3）报告疯狂的“级联”错误的情况下成功完成后续阶段。 所以会发生什么，你得到一个错误，你修复它，然后突然下一个编译阶段可以运行，它会发现更多的错误。

基本上，如果程序如此混乱以至于我们甚至无法验证有关其类和方法的基本事实，那么我们就无法可靠地为方法体提供错误。 如果我们无法分析lambda体，那么我们就无法可靠地为其转换为表达式树提供错误。 等等; 在很多情况下，后期阶段需要知道前面的阶段完成没有错误。

这种设计的好处在于：（1）你首先得到最“基本”的错误，没有很多嘈杂，疯狂的级联错误，以及（2）编译器更强大，因为它不需要尝试对语言的基本不变量被破坏的程序进行分析。 缺点当然是你的情况：你有50个错误，你修复它们，突然又出现了50个。

Answer 2

当然它会在某个时候停止。

即使在1次错误之后，其余的都是可疑的。 编译器将尝试恢复，但不能保证成功。

因此，在任何非平凡的项目中，在停止第一个错误（理论上最好的事情）和在不可靠的状态下耕作之间是一个实际的决定。

最正确的操作是在1次错误后停止，但这会导致繁琐的“一次修复1”情况。 因此编译器会尝试重新同步到已知状态并报告下一个状态。 但是错误可能会导致跟随它的正确代码出现错误错误，所以在某些时候它会停止合理。

请参考您自己的案例：经过一些修复后，400+会变为120。

Answer 3

它可以根据MSDN进行配置

默认情况下，最大数量为200个错误和警告。