none
Why is exception not caught and how to get around it? RRS feed

  • Frage

  • Hi folks,

    I have the following coding (linq for XML):

          try
          {
            personsByAttrib =
              from personElements in theXDocument.Descendants(CConstants.xmlElementPerson)
              where personElements.Attribute(CConstants.xmlAttributeChecked).Value.ToString() == checkAttrValue
              select personElements;
          }
          catch (Exception e)
          {
            MessageBox.Show(e.Message + ": Command aborted. Please execute the \"Highlight\" command first");
          }
    

    For some of the "personElements" in the XDocument the requested attribute does not exist and a "NullReferenceException" occurs. I already tried to get past this exception by a try-catch block, but when executing this code, catch will not work.

    Best regards

    WolfiG

    Freitag, 4. Februar 2011 19:06

Antworten

  • Hallo W.,

    Schliesse die Linq2XML-Query in Klammer ein und setze zum Beispiel ein ToList() dahinter (oder z.B.: personsByAttrib.ToArray(); ), um die Ausführung der Query zu erzwingen.

    [Verzögerte Ausführung und verzögerte Auswertung in LINQ to XML]
    http://msdn.microsoft.com/de-de/library/bb943859.aspx



    Ansonsten dazu relevant: [ How do you guard for Null Reference exceptions in Linq To Xml? - Stack Overflow]

    ciao Frank
    Freitag, 4. Februar 2011 19:37
  • Hi WolfiG,

    Welcome to our German forum. If you're speaking German, please let us switch to it.

    Now to your question about the the catch block not catching the Exception. The try/catch does not work, because the exception simply does not happen in that scope. As Frank already mentioned, the exception is thrown instead at a later point in time: The query execution is deferred until you materialize the results (e.g. when you call ToList() or when you enumerate through a resulting IEnumerable<T> collection). The query does not execute where you define it, that's simply the point where the debugger stops.

    This is why you will have to enlarge your try/catch-block to contain the rows of code where the query is materialized. The exception will be catched so you can handle it.

     

    Hallo WolfiG,

    Der Ausnahmefehler kann nicht in Deinem try/catch-Block behandelt werden, da er sich in einem anderen Ausführungskontext, außerhalb dieses Blocks ereignet. Die Abfrage wird eben nicht dort ausgeführt, wo man sie definiert, sondern später, wenn sie materialisiert/ausgeführt wird (z.B. während der Enumeration über eine IEnumerable<T>-Kollektion). Es ist etwas irreführend. Der VS-Debugger bleibt im Code im try/catch-Block stehen, der tatsächliche Ausführungsort ist aber ein anderer.

    Am einfachsten ist es, wenn Du den try/catch-Block so erweiterst, dass er die Codezeilen einbezieht, wo sich die Query materialisiert. Die Ausnahme wird dann gefangen und Du kannst sie behandeln.

    Marcel

    Sonntag, 6. Februar 2011 09:54
    Moderator

Alle Antworten

  • Hallo W.,

    Schliesse die Linq2XML-Query in Klammer ein und setze zum Beispiel ein ToList() dahinter (oder z.B.: personsByAttrib.ToArray(); ), um die Ausführung der Query zu erzwingen.

    [Verzögerte Ausführung und verzögerte Auswertung in LINQ to XML]
    http://msdn.microsoft.com/de-de/library/bb943859.aspx



    Ansonsten dazu relevant: [ How do you guard for Null Reference exceptions in Linq To Xml? - Stack Overflow]

    ciao Frank
    Freitag, 4. Februar 2011 19:37
  • Found a workaround:

          if (!theXDocument.Descendants(CConstants.xmlElementPerson).Any(test => test.Attribute(CConstants.xmlAttributeChecked) == null ) )
          {
            personsByAttrib =
              from personElements in theXDocument.Descendants(CConstants.xmlElementPerson)
              where personElements.Attribute(CConstants.xmlAttributeChecked).Value.ToString() == checkAttrValue
              select personElements;
          }
          else
          {
            MessageBox.Show(": Command aborted. Please execute the \"Highlight\" command first");
          }
    

    Still I do not know why the try-catch does not work.

    Best regards

    WolfiG

    Freitag, 4. Februar 2011 19:50
  • Hallo W.,

    Dir sind lange Möglichkeiten dafür genannt worden, wie man in diesem Fall try-catch Exception erzwingt.
    Auch, wie man das null-Handling angeht. Dein Workaround sollte eher vermieden werden, da sonst die Performance doppelt so schlecht ist und auch vom Schreibaufwand und der Lesbarkeit her eher ungünstig.


    ciao Frank
    Samstag, 5. Februar 2011 11:40
  • Hi WolfiG,

    Welcome to our German forum. If you're speaking German, please let us switch to it.

    Now to your question about the the catch block not catching the Exception. The try/catch does not work, because the exception simply does not happen in that scope. As Frank already mentioned, the exception is thrown instead at a later point in time: The query execution is deferred until you materialize the results (e.g. when you call ToList() or when you enumerate through a resulting IEnumerable<T> collection). The query does not execute where you define it, that's simply the point where the debugger stops.

    This is why you will have to enlarge your try/catch-block to contain the rows of code where the query is materialized. The exception will be catched so you can handle it.

     

    Hallo WolfiG,

    Der Ausnahmefehler kann nicht in Deinem try/catch-Block behandelt werden, da er sich in einem anderen Ausführungskontext, außerhalb dieses Blocks ereignet. Die Abfrage wird eben nicht dort ausgeführt, wo man sie definiert, sondern später, wenn sie materialisiert/ausgeführt wird (z.B. während der Enumeration über eine IEnumerable<T>-Kollektion). Es ist etwas irreführend. Der VS-Debugger bleibt im Code im try/catch-Block stehen, der tatsächliche Ausführungsort ist aber ein anderer.

    Am einfachsten ist es, wenn Du den try/catch-Block so erweiterst, dass er die Codezeilen einbezieht, wo sich die Query materialisiert. Die Ausnahme wird dann gefangen und Du kannst sie behandeln.

    Marcel

    Sonntag, 6. Februar 2011 09:54
    Moderator