For one of my [WIP] project, I extended the dictionary class a lot with specific handlers, as such I determined that I wanted
TypeError exceptions to be specific to my project's parser. I extended the exception class like this:
"""Exception classes """ class ValveException(Exception): """Base Exception """ pass class ValveKeyError(ValveException): """KeyError specific to map parsing """ pass class ValveTypeError(ValveException): """TypeError specific to map parsing """ pass
Exceptions are raised by either the recursive parser loop, or by the extended dictionaries when they are given a key that is not whitlisted:
if not datatype in self.datatypes: raise ValveKeyError( "Unknown datatype [ %s ]" % datatype ) ...
if not hasattr(self, vmf_key): raise ValveKeyError( 'Key `%s` not allowed in %s' % (key, self._type()) ) ...
if not value.allow_multiple: raise ValveTypeError( "Type %s does not allow allow multiple values" % (type(value)) ) ...
if any([ value is None, not type(value)(allowedcontainer(value)) == value ]): # We do not get the same value, we cannont cast raise ValveTypeError( ("Illigal Type %s for key `%s`, " + "expected Type %s for value `%s`") % ( type(value), key, allowedcontainer, value ) ) ...
And Lastly, the exception handler:
except ValveException as err: self._parseerrors.append( 'Ln %s: %s' % (self.i, err) )
Which works for me and I am content to leave it alone; This lets me
except MyTypeError and
except MyKeyError as to distinguish between a parsing problem, and a coding problem.
Is this distinction between Coding Fault, and Parsing Fault a good distinction to have? I don't know if I feel comfortable using the native
TypeErrors in place, not until I was absolutely sure that there were no ways they could be a coding fault, as that might cause exception routes to handle bad parser input handle a coding exception.
Thoughts and insights are welcome, as well as constructive criticism regarding the post's subject matter.
 Added Exceptions Raise calls (with links), as requested.
Note: The revision posted was non-stable, I have since published a revision that at least can run [d8bf9f18] Though it is widely irrelevant to the question posed in this thread.