Si (false == true) exécute un bloc quand une exception est lancée à l'intérieur

Question

J'ai un problème assez étrange qui se produit.

C'est mon code

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

Semble vraiment simple, il ne devrait pas frapper l' Console.WriteLine ou throw. Pour une raison quelconque, il est toujours en train de frapper l' throw.

Si je déplace le throw dans sa propre méthode, puis il fonctionne très bien. Ma question est comment est-il en ignorant l' if bloquer et frapper l' throw new Exception

EDIT 1 j'ai mis à jour mon code pour inclure la signature, j'ai supprimé tout ce ne sont pas liées à ce problème et il a couru, il arrive encore

Answer 1

Il semble être le bug en async méthode, le code n'est pas exécuté mais débogueur étapes jusqu'à la ligne throw déclaration. Si il y a quelques lignes de code avant d' throw dans if ces lignes sont ignorées, étapes de débogueur seulement jusqu'à la ligne throw déclaration.

Aussi, si vous n'utilisez pas variable - if (false) ou if (true == false) alors débogueur étapes à la bonne ligne de code à l'accolade fermante.

Ce bogue a été posté par @Matthew Watson à Visual Studio team (lien n'est pas disponible en ce moment).

Voir également la question similaire, - Condition de vérifier dans la méthode async

EDIT (2017/10/06):

Le problème ne peut pas être reproduit dans VS 2017 15.3.5 à l'aide .Net Framework 4.7. Semble comme VS l'équipe a résolu ce problème.

Answer 2

Juste un additif pour la réponse, j'ai récemment rencontré le même problème, et regarda vers le réel x86 code dans le débogueur, et il a été généré d'une manière bizarre comme ceci (simplifié):

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

Ainsi, au lieu de directement sauter à la dernière des instructions de la méthode, il ne double saut, où je crois que le deuxième saut inconditionnel est à tort reconnu comme une partie du code à l'intérieur d' if bloc.

Donc, je présume que ce bug pourrait être liée à un compilateur JIT.