Commons Digester
  1. Commons Digester
  2. DIGESTER-85

[digester] Include filename or uri if Digester.parse(File file or String uri throws a SAXException

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.0
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      Would make debugging easier.

      A try catch SAXException block around the getXMLReader().parse(input); statements in the parse
      File and parse(String would allow the SAX Exception to be caught, taken apart, an error statement
      with file or uri added, and thrown.

      But how to capture the first stack trace? Use NestedExceptions from jakarta-commons-lang? Use
      org.apache.commons.lang.exception.ExceptionUtils.getStackTrace and and cram the first stack
      trace in the with new SAXExceptions? Or avoid the new dependecy on lang and do something
      else?

        Activity

        Hide
        Simon Kitching added a comment -

        I don't understand this request. Under what circumstances would the user code
        that called digester.parse and caught the exception not know the filename/uri of
        the xml input it was parsing?

        In other words, why is this not acceptable?

        String filename="foo.xml";
        try

        { digester.parse(filename); }

        catch(SAXException ex)

        { System.err.println( "Failed to process file [" + filename + "]:" + ex.getMessage()); }
        Show
        Simon Kitching added a comment - I don't understand this request. Under what circumstances would the user code that called digester.parse and caught the exception not know the filename/uri of the xml input it was parsing? In other words, why is this not acceptable? String filename="foo.xml"; try { digester.parse(filename); } catch(SAXException ex) { System.err.println( "Failed to process file [" + filename + "]:" + ex.getMessage()); }
        Hide
        Simon Kitching added a comment -

        As there has been no response to my comment of 2005-01-25, I'm going to assume
        this issue can be closed. Erik, if you wish to follow up on this then please
        reopen this entry and attach more details.

        Show
        Simon Kitching added a comment - As there has been no response to my comment of 2005-01-25, I'm going to assume this issue can be closed. Erik, if you wish to follow up on this then please reopen this entry and attach more details.
        Hide
        Henri Yandell added a comment -

        (Fixing JIRA import error)

        Show
        Henri Yandell added a comment - (Fixing JIRA import error)
        Hide
        Erik Meade added a comment -

        Often when the digester is used by a third party, whose code the developer is using (like tomcat) the error handling does not output the file (url). Rather than a convention that all users of the digester "get the error handling right" (which personally, I rarely see, given the number of times and hours I spend tracking down bad files), if the file (url) was included in exception from digester, then from a tracking down the bad file point of view, it would just work.

        Show
        Erik Meade added a comment - Often when the digester is used by a third party, whose code the developer is using (like tomcat) the error handling does not output the file (url). Rather than a convention that all users of the digester "get the error handling right" (which personally, I rarely see, given the number of times and hours I spend tracking down bad files), if the file (url) was included in exception from digester, then from a tracking down the bad file point of view, it would just work.
        Hide
        Simone Tripodi added a comment -

        Fixed on Digester3 /trunk, see r1140083.

        There's no need to decorate the thrown exception, filename or uri have been logged at error level: since the request is focused on monitoring errors from 3rd-parties Digester use, logging which resource caused the error is more than enough.

        Show
        Simone Tripodi added a comment - Fixed on Digester3 /trunk, see r1140083 . There's no need to decorate the thrown exception, filename or uri have been logged at error level: since the request is focused on monitoring errors from 3rd-parties Digester use, logging which resource caused the error is more than enough.
        Hide
        Simone Tripodi added a comment -

        included in Apache Commons Digester 3.0 release

        Show
        Simone Tripodi added a comment - included in Apache Commons Digester 3.0 release

          People

          • Assignee:
            Simone Tripodi
            Reporter:
            Erik Meade
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development