¿El compilador de C# no informa todos los errores a la vez en cada compilación?

Cuando estoy compilando este proyecto, aparece como más de 400 errores en la ventana Lista de errores, luego voy a sitios de error, arreglo alguno, y el número va para decir más de 120 errores, y luego después de corregir algunos más, el siguiente compila informes como 400+ de nuevo. Puedo ver que vienen diferentes archivos en la ventana Lista de errores, así que estoy pensando que el compilador aborta después de una cierta cantidad de errores.¿El compilador de C# no informa todos los errores a la vez en cada compilación?

Si es así, ¿cuál es la razón de esto? ¿No se supone que reúne todos los errores que están presentes en el proyecto, incluso si tienen más de 10 K +?

Fuente

2011-01-14 Joan Venge

A menudo, corregir algunos errores pone en foco otros errores. No es fácil decir que un automóvil tiene un problema de bajo consumo de combustible * hasta que * solucione el problema del indicador de combustible averiado. – Ani

@Ani: Gracias, sé a qué te refieres, pero la mayoría de los errores son errores de sintaxis en diferentes archivos y la mayoría de ellos son ignorados por el archivo de lo que puedo decir. –

Quizás la pregunta más importante es ¿por qué tienes más de 400 errores? – abelenky

He tenido la intención de escribir un artículo de blog sobre esto.

Es posible que simplemente esté corriendo un límite codificado para la cantidad de errores informados. También es posible que te encuentres con un escenario más sutil e interesante.

Hay una gran cantidad de heurísticas en el compilador de línea de comandos y el compilador IDE que intentan administrar el informe de errores. Tanto para mantenerlo manejable para el usuario como para hacer que el compilador sea más robusto.

En pocas palabras, la forma en que funciona el compilador es que trata de obtener el programa a través de una serie de etapas, que se puede leer aquí:

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

La idea es que si una etapa temprana obtiene una error, es posible que no podamos completar con éxito una etapa posterior sin (1) entrar en un ciclo infinito, (2) bloqueos o (3) informar errores en cascada "enloquecidos". Entonces, lo que sucede es que obtienes un error, lo arreglas y de repente se puede ejecutar la siguiente etapa de compilación, y encuentra un montón más de errores.

Básicamente, si el programa está tan desordenado que ni siquiera podemos verificar hechos básicos sobre sus clases y métodos, entonces no podemos dar errores confiables para cuerpos de métodos. Si no podemos analizar un cuerpo lambda, entonces no podemos dar errores confiables para su conversión a un árbol de expresiones. Y así; hay muchas situaciones en las que las etapas posteriores necesitan saber que las etapas previas se completaron sin errores.

El lado positivo de este diseño es que (1) primero se obtienen los errores que son los más "fundamentales", sin muchos ruidos cascadas, y (2) el compilador es más robusto porque no lo hace No debe intentar hacer análisis en programas donde las invariantes básicas del lenguaje están rotas. El lado negativo es, por supuesto, su escenario: que tiene cincuenta errores, los arregla a todos, y de repente aparecen cincuenta más.

Fuente

2011-01-15 06:21:39

Gracias Eric. Solo vi esto. Tiene mucho sentido. Por errores en cascada, ¿quiere decir que si falta un corchete, puede informar muchos errores que resultan de él, como que algunos métodos se informarán fuera de la clase, etc. cuando falta el corchete de cierre de un método anterior? –

@Joan: exactamente, sí. –

Se es configurable según MSDN

Por defecto, el número máximo es de 200 errores y advertencias.

Fuente

2011-01-14 23:14:01

Lo intenté pero no hice nada, también dice que esto es para proyectos de db. –

@Joan, notado que ahora, es relevante para Visual Studio, ¿así que tal vez debería mantener la respuesta? –

Por supuesto, creo que aún es útil para algunos. –

Por supuesto, se detendrá en algún momento.

Incluso después de 1 error, el resto es dudoso en el mejor de los casos. Un compilador intentará recuperarse, pero no está garantizado que tenga éxito.

Por lo tanto, en cualquier proyecto no trivial, es una decisión práctica entre detenerse en el primer error (en teoría, lo mejor que se puede hacer) y arar en un estado poco confiable.

La acción más correcta sería detenerse después de 1 error, pero eso daría lugar a una tediosa situación de "solución 1 a la vez". Entonces, un compilador intenta resincronizar a un estado conocido e informar el siguiente. Pero un error puede causar errores falsos en el código correcto que lo sigue, por lo que en algún momento deja de ser sensato.

Consulte su propio caso: 400+ pasa a 120 después de algunas correcciones.

Fuente

2011-01-14 23:19:30

Gracias, ¿por qué dijiste "formalmente"? ¿Ya no? –

Reescribí un poco. –

Entendido, ¿pero en ese caso no muestra la solidez del compilador? –

¿El compilador de C# no informa todos los errores a la vez en cada compilación?

Respuesta

Cuestiones relacionadas