2009-09-10 19 views
5

Ho il seguente codice in uno dei nostri progetti di pagine web:Non riesco a gestire XMLException?

  XmlDocument xDoc = new XmlDocument(); 
      xDoc.Load(File.FullName); 

      //work through each print batch in this queue file 
      try 
      { 
       XmlNodeList nodeList = xDoc.SelectNodes("Reports/PrintBatch"); 
       foreach (XmlNode printBatch in nodeList)//xDoc.SelectNodes("Reports/PrintBatch")) 
       { 
        PrintBatch batch = new PrintBatch(); 
        batch.LoadBatch(printBatch, File.Extension); 
        this.AddBatch(batch); 
       } 
      } 
      catch (XmlException e) 
      { 
       //this report had an error loading! 
       Console.WriteLine(e.Message); 
      } 

Ci vuole fondamentalmente un file batch XML e lo carica in su come un oggetto, pronti per essere elaborati.

Sta funzionando bene, fino a poco tempo fa, quando uno dei file XML è stato trovato per contenere un carattere nullo (che non è valido in XML).

Quando si tenta di elaborare il file "dudd", otteniamo la seguente eccezione:

alt text http://blog.ianmellor.co.uk/images/xml_err.jpg

Ok finora .. ma quando poi cerchiamo di "continua" o "scavalcare", Mi aspetto che fluisca nel blocco delle catture. Tuttavia, non lo fa; abbiamo semplicemente avere uno schermo rosso della morte:

alt text http://blog.ianmellor.co.uk/images/xml_err2.jpg

Che cosa sto facendo di sbagliato?

+0

Hanno tentato di rilevare SystemException, Exception, System.Xml.XmlPath.XPathException con un successo simile. – Sk93

+0

per curiosità, cosa succede quando si modifica il catch (XmlException e) {} per rilevare {}? – Razzie

+0

Razzie: esattamente lo stesso. Lancia lo schermo rosso della morte. – Sk93

risposta

5

E 'perché non hai scritto

xDoc.Load(File.FullName); 

all'interno del blocco try. Questo è il motivo per cui l'eccezione non è stata gestita.

+0

Ecco, grazie! Ma potresti spiegare (o indicare da qualche parte) perché è così? – Sk93

+1

È possibile rilevare un'eccezione solo se si verifica in un blocco try corrispondente al blocco catch. – rahul

+0

Ma la linea che stava lanciando l'errore (.SelectNodes) era all'interno del try catch .. Ma penso di sapere ora; l'oggetto XMLDocument utilizza l'associazione lazy? – Sk93

2

L'altra risposta relativa all'inserimento di Load() nel blocco try è corretta, ma in realtà non spiega il motivo per cui SelectNodes() "appare" per generare una XmlException che non viene rilevata.

La risposta effettiva è che il debugger è confuso/non sincronizzato con il codice sorgente e sta effettivamente mostrando la riga sbagliata come causa dell'eccezione.

Dovrebbe davvero puntare a xDoc.Load (File.FullName); , nel qual caso sarebbe chiaro che questa chiamata dovrebbe essere all'interno del blocco try.

Perché? Si noti XmlLoader.LoadNode() nell'ultima riga della traccia dello stack. In .NET Reflector è possibile vedere che il metodo XmlDocument.Load() (in profondità nelle sue viscere) chiama il metodo LoadNode().

Tuttavia, anche in Reflector, si può vedere che il metodo SelectNodes() non chiama LoadNode() in nessuna parte dell'implementazione interna.

Quindi, in base alla traccia dello stack, l'eccezione non può essere stata causata da SelectNodes().

Ho visto il debugger confondersi in questo modo prima di quando è stato fatto un cambio di codice e il debug è iniziato, ma i simboli di debug non sono stati aggiornati correttamente. Prova a pulire e ricostruire la tua soluzione per aggiornare i simboli di debug.

+1

Ho riavviato, pulito la soluzione, ricostruito e ritestato e non riesce ancora sulla linea "sbagliata". Eppure infili le linee all'interno del fermo di prova e attraversalo, si rompe sulla linea "carico" .. dispari – Sk93

Problemi correlati