Broken file raises GPXException, XMLSyntaxError, TypeError about gpxpy

[tkrajina]

Hi @johnjohndoe thanks for your bug submission. I changed and commited a new version. The parse() method will now fail on invalid XML file and the code where your problem was manifesting is deleted. Also, I deleted the is_valid() method (it there is a exception on parse() -- no need to check is_valid() later).

Hope this is OK for you?

[johnjohndoe]

@tkrajina Looks good so far.
One thing I would rewrite is how you handle exceptions. I would not handle all errors as generic exceptions but add a specific XMLSyntaxError except block before. This is the error you know of at the point in time.

except XMLSyntaxError as e:
    mod_logging.debug('Error in:\n%s\n-----------\n' % self.xml)
    mod_logging.exception(e)
    raise mod_gpx.GPXException('Error parsing XML: %s' % str(e))
except Exception as e:
    mod_logging.debug('Error in:\n%s\n-----------\n' % self.xml)
    mod_logging.exception(e)
    raise mod_gpx.GPXException('Unknown error: %s' % str(e))

If you can accept a crash on an unknown error you could even omit the generic except block.

[tkrajina]

What about this: 8accbce ?

The idea is to have two kinds of gpxpy exceptions, one for invalid XML files and the other for invalid valid-XML-invalid-GPX files. You can choose if to detect all exceptions with GPXException or XML-specific with GPXXMLSyntaxException. If GPXXMLSyntaxException -- you can retrieve the original (which can be lxml or minidom) exception with e.original_exception.

[johnjohndoe]

@tkrajina I disagree. I find it more complicated to handle multiple GPX*Exceptions as a user of the library. What would be the benefit of yet another wrapper for an exception caused by an internal module not part of the library? All the user needs is the original error message which you wrap into a GPXException. This is good enough imho.

[johnjohndoe]

@tkrajina Please consider this comment by abarnert with regards to exception handling.