Fallimenti silenziosi in C #, eccezioni apparentemente non gestite che non bloccano il programma

In un’app Winforms, nell’evento Load di un modulo, aggiungere la seguente riga:

throw new Exception(); 

ed esegui l’applicazione. Ha funzionato senza problemi. Questo è chiamato un errore silenzioso, puoi provare ad aggiungere messagebox prima e dopo, e presto scoprirai che invece di arrestare l’applicazione, l’istruzione throw esce dall’evento Load.

Sono sicuro che non è necessario spiegare quanto sia brutto e pericoloso.

Mi chiedevo comunque delle ragioni (probabilmente storiche) dietro questo terrificante comportamento. Sono sicuro che non si tratta di una decisione di progettazione, probabilmente di non scelta o pigrizia. Qualcuno lo sa?

Sarei felice se qualcuno potesse indicarmi una lista di eventi che potrebbero causare anche gravi fallimenti.

Ecco un frammento del mio codice – Non ho idea di come possa essere d’aiuto – ma, eccolo qui:

 using System; using System.Collections.Generic; using System.Linq; using System.Windows.Forms; namespace WindowsFormsApplication1 { static class Program { ///  /// The main entry point for the application. ///  [STAThread] static void Main() { Form f = new Form(); f.Load += new EventHandler((x, y) => { throw new Exception(); }); Application.Run(f); } } } 

EDIT Sembra che non sia successo a tutti. Io uso: fw 3.5, winforms, vs 2008, vista x64, nuovo progetto pulito di winforms, con il codice sopra menzionato.

Questo è un problema noto sui sistemi x64 :

Questo è un problema noto sulla piattaforma del sistema operativo a 64 bit. Il motivo è che il core del sistema operativo a 64 bit non consente l’eccezione della modalità utente attraverso gli stack in modalità kernal. L’eccezione è inghiottita dal sistema operativo in modo scorretto. Ciò accade nel gestore FormLoad, perché viene chiamato in un callback del sistema operativo. Il sistema operativo a 32 bit non lo fa, quindi non lo riproduce.

Il team del sistema operativo sta esaminando i problemi correlati. Nel frattempo, devi ovviare a questo problema. L’triggerszione di “Interrompi all’eccezione di prima scelta” farà arrestare il debugger in questo scenario. Ma fa sì che il debugger si fermi molto spesso, quindi potresti voler farlo solo quando trovi un problema.

Il bug report collegato è stato aggiornato l’ultima volta a febbraio 2008 e non indica cosa sia successo da allora.

Posso riprodurre la maggior parte dei comportamenti del poster sul mio sistema a 32-bit qui, e posso riprodurre il comportamento dell’OP sul mio PC da lavoro a 64-bit (Vista SP2, 3.5SP1 Framework).