PVL Exception class round up?

[Ross Beyer]

In the 1.0.0-alpha.2 architecture there are now three exception classes:

pv.decoder.QuantityError(Exception)
pvl.lexer.LexerError(ValueError)
pvl.parser.ParseError(Exception)

As you can see, they're in the module which typically throw them. Some just descend from Exception, and one from ValueError.

I think we should probably round them up. Maybe into a pvl.exception module, and craft a PVLError exception class from which they all descend? Thoughts?

[Dr. Andrew Annex]

I think it's desirable, but are there built in exceptions that make sense to inherit for quantity and parse errors? If not (there may not be) then it sounds fine to me, you can also import those exceptions to the modules they are currently located for backwards compatibility in the code.

[Ross Beyer]

@AndrewAnnex yes, we can work multiple inheritance so that LexerError (which I already subclassed from ValueError) is both a ValueError and a PVLError.

And yes to the backwards compatibility, that's actually how I got on this, from an e-mail from @jessemapel about how he had some code that was checking for the old decoder.ParseError that didn't exist.

[Jesse Mapel]

I would error towards inheriting only from built in exceptions when possible. Moving them into an exceptions module or just directly into the root module would also be great.

[Michael Aye]

in terms of code management, i usually put my exceptions into an exceptions module, and if I want them available in the root namespace, i import them in the init file.

[Ross Beyer]

Have LexerError (maybe also ParseError) print out more surrounding contextual information about the line that it occurs in (from discussion in #59).