Se (false == true) esegue il blocco quando viene generata l'eccezione

152

Ho un problema piuttosto strano che si sta verificando.

Questo è il mio codice:

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

Sembra davvero semplice, non dovrebbe colpire il Console.WriteLineo il throw. Per qualche ragione colpisce sempre il throw.

Se sposto thrownel suo metodo, allora funziona benissimo. La mia domanda è come sta ignorando il ifblocco e colpendo throw new Exception:

EDIT 1: ho aggiornato il mio codice per includere la firma, ho rimosso tutto ciò che non riguardava questo problema e l'ho eseguito, succede ancora.

c# .net visual-studio .net-core

— Giorgio
fonte

@TimSchmelter l'immagine è in fase di debug, l'evidenziazione gialla è dove si trova il codice

— George

Ho appena creato un'app console core vuota, ho incollato il tuo codice nella Maine .... sorpresa, norepro. O ti sbagli o ti sei perso alcuni dettagli importanti.

— Jamiec,

È questo un asyncmetodo per caso? Perché sembra simile a stackoverflow.com/questions/42528458/…

— Matthew Watson

@George: ancora nessuna prova perché potresti usare vecchi simboli di debug. Ricompilare in modalità debug e quindi ricominciare.

— Tim Schmelter

@TimSchmelter Ho ricompilato, pulito, riaperto il progetto ha provato diversi modi di fare l'if, ma è sempre lo stesso

— George

Risposte:

176

Sembra essere il bug nel asyncmetodo, il codice non viene effettivamente eseguito ma il debugger passa alla riga con l' throwistruzione. Se ci sono alcune righe di codice prima che l' throwistruzione all'interno di ifqueste righe venga ignorata, il debugger passa solo alla riga con l' throwistruzione.

Inoltre, se non si utilizza la variabile - if (false)o if (true == false)quindi il debugger passa alla corretta riga di codice - alla parentesi graffa di chiusura.

Questo bug è stato pubblicato da @Matthew Watson nel team di Visual Studio (il link non è disponibile ora).

Vedi anche la domanda simile - Verifica delle condizioni nel metodo asincrono

EDIT (2017/10/06):

Il problema non può essere riprodotto in VS 2017 15.3.5 usando .Net Framework 4.7. Sembra che il team VS abbia risolto questo problema.

— Doskoch romano
fonte

Grazie, senza sapere che questo è un bug nel debugger che probabilmente sarei impazzito.

— George

121

Un bug nel debugger? Molto meta. :) (cantando non ho mai avuto meta bug come questo prima ... )

— Simba

@George Spero non ti dispiaccia, ho preso il tuo campione e ho creato un'app per console utilizzandola, e l'ho allegata al problema VS a cui Roma ha legato.

— Obsidian Phoenix,

@ Simba: Dimmi che non hai mai usato un debugger per eseguire il debug.

— Giosuè

Hmm. Sembra che il bug potrebbe essere nelle informazioni di debug generate dal compilatore piuttosto che nel debugger stesso. Aspetterò che MS riconosca il bug di Connect prima di votare su o giù.

— Adrian McCarthy,

Solo un addendum alla risposta, di recente ho riscontrato lo stesso problema e ho guardato al codice x86 effettivo nel debugger, ed è stato generato in un modo strano come questo (semplificato):

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

Quindi, invece di saltare direttamente alle ultime istruzioni del metodo, fa un doppio salto, dove credo che il secondo salto incondizionato venga erroneamente riconosciuto come parte del codice all'interno del ifblocco.

Quindi vorrei ipotizzare che questo errore potrebbe essere correlato al compilatore JIT.

— Serge Semenov
fonte