2016-04-05 10 views
10

Quando compilo un'app UWP con il compilatore .NET nativo e accendo le ottimizzazioni del codice (essenzialmente la modalità di rilascio), ottengo un NullReferenceException quando provo ad accedere all'eccezione effettiva in il blocco delle cattureIl codice nel gestore di eccezioni filtrate genera NullReferenceException quando si accede all'eccezione

codice di esempio:

try 
{ 
    throw new ArgumentNullException("Param"); 
} 
catch (ArgumentNullException ex) when (ex.ParamName == "Param") 
{ 
    ErrorBlock.Text = ex.ParamName; // ErrorBlock is a TextBlock in the xaml 
} 
catch (Exception) 
{ 
} 

Si va in blocco catch corretto, e lancia un NullReferenceException quando accedo ex. Questo fallisce solo se sono attive entrambe le ottimizzazioni Native e di codice .Net.

Quali sono le cause di questo problema?

+1

@Pan perché rimuovere i tag? Sembra correlato a questa modalità di compilazione e quindi probabilmente a un problema di compilazione con .NET nativo. –

+0

Perché sono irrilevanti. 'exc.Message' è nullo. Questa è una NulLReferenceException semplice. L'OP ha chiamato il costruttore che accetta solo un nome parametro –

+3

No, non lo è ... Il messaggio è predefinito. Si prega di provare questo codice te stesso. –

risposta

2

Io lavoro su .NET Runtime nativo e team di compilazione.

Questo è un bug all'interno del nostro compilatore. Puoi pensare a ciascuna regione di gestione delle eccezioni (prova, cattura, infine, quando) come una piccola funzione o "funclet". Perdiamo la traccia dell'oggetto di eccezione quando si imposta lo stack per il "quando" (ovvero il blocco del filtro). Questo errore viene corretto in Windows Tools 1.3 che, in assenza di importanti ostacoli, dovrebbe essere spedito tra una o due settimane. Verrà visualizzato come aggiornamento per gli utenti che hanno installato VS 2015 Update 2.

Fatemi sapere se avete altre domande.

+0

Grazie a @Matt! Ho visto comportamenti leggermente diversi in 3 scenari intorno a questo: non asincrono, asincrono ma non atteso e asincrono + atteso. Darò un colpo a tutti e 3 quando uscirà l'aggiornamento. – FUR10N

+0

Eccellente. Per favore, facci sapere come va.Amiamo sentire gente da [email protected] –

5

Non sono esattamente sicuro del motivo per cui sta andando storto (sono stato eseguito il debug per un po 'di tempo), ma la mancanza di await mi ha incuriosito.

Se non attendono il metodo ShowAsync il codice viene eseguito senza un problema (ovviamente è necessario effettuare il metodo async se non hai fatto che ancora):

await new MessageDialog("Argument null exception: " + argEx.Message).ShowAsync(); 

Mentre il blocco di codice senza la await fallito. Non sono sicuro se questo è un bug o qualcosa che dovresti avere risolto ...

+0

Hmm, ha funzionato anche per me! Non avevo realizzato che fosse collegato ad async/attendi. Il codice effettivo in cui ho trovato questo non è in attesa di un risultato particolare in base alla progettazione (è tutto in ICommands comunque, quindi sarebbe vuoto asincrono). Non penso che tu debba essere obbligato ad aspettarlo comunque, giusto? – FUR10N

+0

Sì, ogni 'async' dovrebbe essere' await'ed. –

+0

Questa è un'attività a esecuzione prolungata e non è necessario pianificare una continuazione in seguito. Voglio il comportamento fire-and-forget qui. Attenderlo non è davvero un'opzione. – FUR10N

Problemi correlati