c# - studio - ¿Por qué la condición de punto de interrupción del depurador permite una declaración de asignación como condición bool?

la depuración de scripts de chrome en visual studio está habilitada

Question

Esto es muy peligroso, así que me pregunto por qué está permitido. Como a menudo necesito cambiar entre VB.NET y C #, a veces agrego condiciones de punto de interrupción como las siguientes:

foo = "bah"

Quiero detenerme si la variable de string foo es "bah , entonces la forma correcta era usar foo == "bah" lugar de foo = "bah" .

Pero funciona". No obtienes advertencias o errores durante la compilación o el tiempo de ejecución. Pero en realidad esto modifica la variable foo , la convierte siempre en "bah" incluso si tiene un valor diferente. Como eso sucede en silencio (el punto de interrupción nunca es alcanzado) es increíblemente peligroso.

¿Por qué está permitido? ¿Dónde está mi error de razonamiento (aparte de confundir la sintaxis de C # y VB.NET)? En C # (a diferencia de VB.NET) una instrucción de asignación devuelve el valor que se le asignó, por lo que no es un bool , sino una string en este caso. Pero una condición de punto de interrupción tiene que ser un bool si bool la casilla "Es cierto" .

Aquí hay un pequeño "programa" de muestra y capturas de pantalla de mi IDE (alemán):

static void Main()
{
    string foo = "foo";
    // breakpoint with assignment(foo = "bah") instead of comparison(foo == "bah"):
    Console.WriteLine(foo);  // bah, variable is changed from the breakpoint window
}

El diálogo de condición de punto de interrupción:

El código como imagen, incluido el punto de interrupción:

Answer 1

Es una consecuencia automática de la sintaxis de C #, común en el grupo de idiomas de llaves rizadas. Una asignación también es una expresión, su resultado es el valor del operando del lado derecho. El depurador no se opone a las expresiones que tienen efectos secundarios, ni sería simple suprimirlas. Podría culparse por no verificar que la expresión tiene un resultado bool , pero el depurador no tiene un analizador de lenguaje C # completo. Esto podría arreglarse en VS2015 gracias al proyecto Roslyn. [Nota: ver el apéndice en la parte inferior].

También es la razón principal por la que los lenguajes de llaves necesitan un operador separado para la igualdad, == vs =. Que en sí mismo debe ser responsable de millones de dólares en errores, cada programador de C comete ese error al menos una vez.

VB.NET es diferente, la asignación es una declaración y el = token es válido tanto para la asignación como para la comparación. Se puede decir por el depurador, elige el operador de igualdad en su lugar y no modifica la variable.

Tenga en cuenta que esto es realmente útil. Te permite solucionar temporalmente un error, forzando el valor de la variable y permitiéndote continuar con la depuración y enfocarte en otro problema. O crea una condición de prueba. Eso es bastante útil. En una vida anterior, escribí un compilador y depurador e implementé "puntos de seguimiento". Descubrió el mismo escenario por accidente y lo dejó en su lugar. Funcionó en un host que dependía en gran medida de las máquinas de estado, anulando la variable de estado mientras que la depuración era increíblemente útil. El accidente, no, no fue tan útil :)

Una nota sobre lo que otros usuarios de SO están observando, depende del motor de depuración que use. La opción relevante en VS2013 es Herramientas + Opciones, Depuración, General, casilla de verificación "Usar modo de compatibilidad administrado". La misma opción existe en VS2012, tenía un nombre ligeramente diferente (no lo recuerdo). Cuando está marcado obtiene un motor de depuración anterior, uno que aún es compatible con C ++ / CLI. Mismo que el utilizado en VS2010.

Así que esa es una solución para VS2013, desmarque la opción de obtener el depurador para verificar que la expresión produzca un resultado de bool. Obtiene algunos más beneficios con ese nuevo motor de depuración, como ver los valores de retorno del método y la compatibilidad con Editar + Continuar para los procesos de 64 bits.

Answer 2

Puedo estar en desacuerdo sobre la naturaleza defectuosa de este comportamiento. Pocos ejemplos para fines de depuración en mi vida si fue útil:
1. Otro hilo modifica algo en tu código.
2. Otro valor actualizado del servicio en db
Entonces, supongo que para casos de sincronización puede ser una característica útil, pero estoy de acuerdo en que puede causar problemas