Si (false == verdadero) ejecuta el bloque cuando se lanza una excepción dentro

152

Tengo un problema bastante extraño que está ocurriendo.

Este es mi código:

private async Task BreakExpectedLogic()
{
    bool test = false;
    if (test == true)
    {
        Console.WriteLine("Hello!");
        throw new Exception("BAD HASH!");
    }
}

Parece realmente simple, no debería golpear el Console.WriteLineo el throw. Por alguna razón, siempre está golpeando el throw.

Si muevo throwa su propio método, entonces funciona bien. Mi pregunta es cómo ignora el ifbloque y golpea el throw new Exception:

Aquí hay alguna evidencia

EDITAR 1: He actualizado mi código para incluir la firma, he eliminado todo lo que no está relacionado con este problema y lo ejecuté, todavía sucede.

c# .net visual-studio .net-core Jorge
fuente
55
@TimSchmelter la imagen se está depurando, el resaltado amarillo es donde está el código
George
55
Acabo de crear una aplicación de consola central en blanco, pegué solo su código en Mainy ... sorpresa, norepro. O te equivocas o te has perdido algunos detalles importantes.
Jamiec
16
¿Es esto un asyncmétodo por casualidad? Porque parece similar a stackoverflow.com/questions/42528458/…
Matthew Watson el
77
@George: todavía no hay evidencia porque podrías usar símbolos de depuración antiguos. Vuelva a compilar en modo de depuración y luego comience nuevamente.
Tim Schmelter
44
@TimSchmelter Recopilé ,
George

Respuestas:

176

Parece ser el error en el asyncmétodo, el código no se ejecuta realmente, pero los pasos del depurador a la línea con la throwdeclaración. Si hay algunas líneas de código antes de que se ignore la throwdeclaración dentro de ifestas líneas, el depurador solo avanza a la línea con la throwdeclaración.

Además, si no utiliza la variable, if (false)o if (true == false)luego los pasos del depurador en la línea de código correcta, en la llave de cierre.

Este error ha sido publicado por @Matthew Watson al equipo de Visual Studio (el enlace no está disponible ahora).

También, vea una pregunta similar - Verificación de condición en método asíncrono

EDITAR (2017/10/06):

El problema no se puede reproducir en VS 2017 15.3.5 con .Net Framework 4.7. Parece que el equipo VS ha solucionado este problema.

Roman Doskoch
fuente
20
Gracias, sin saber que esto es un error en el depurador, probablemente me volvería loco.
George
121
¿Un error en el depurador? Que muy meta. :) (canto I insecto Nunca meta como esto antes ... )
Simba
3
@ George Espero que no te importe, tomé tu muestra y creé una aplicación de consola usándola, y la adjunté al problema VS al que Roma se ha vinculado.
Obsidian Phoenix
55
@Simba: Dime que nunca has usado un depurador para depurarse.
Joshua
3
Hmm Parece que el error podría estar en la información de depuración generada por el compilador en lugar de en el depurador en sí. Esperaré a que MS reconozca el error de conexión antes de votar hacia arriba o hacia abajo.
Adrian McCarthy
10

Solo un apéndice a la respuesta, recientemente encontré el mismo problema y busqué el código x86 real en el depurador, y se generó de una manera extraña como esta (simplificado):

// if (...) {
0001: jne 0006
...
0006: jmp 0007
// }
0007: ret

Entonces, en lugar de saltar directamente a las últimas instrucciones del método, hace doble salto, donde creo que el segundo salto incondicional se reconoce erróneamente como parte del código dentro del ifbloque.

Entonces, especularía que este error podría estar relacionado con el compilador JIT.

Serge Semenov
fuente