Related to #12 and #39.
In various places, the library raises exception types that don't seem entirely appropriate; for example, decoding an ID with a bad length raises an IOError, where something like a TypeError or ValueError would be more appropriate.
Also, for easier catching of ebmlite exceptions, a couple of custom exception subclasses would help (derived from an appropriate standard exception types). The custom types might also inherit from the types of exceptions currently raised for backwards compatibility, but that goes against the first point.
Either proposal might break some compatibility with existing code using ebmlite, however; it might require some minor refactoring, changing the exception types caught. The latter would be lower impact.
Related to #12 and #39.
In various places, the library raises exception types that don't seem entirely appropriate; for example, decoding an ID with a bad length raises an
IOError, where something like aTypeErrororValueErrorwould be more appropriate.Also, for easier catching of
ebmliteexceptions, a couple of custom exception subclasses would help (derived from an appropriate standard exception types). The custom types might also inherit from the types of exceptions currently raised for backwards compatibility, but that goes against the first point.Either proposal might break some compatibility with existing code using
ebmlite, however; it might require some minor refactoring, changing the exception types caught. The latter would be lower impact.