For one of my [WIP] project, I extended the dictionary class a lot with specific handlers, as such I determined that I wanted KeyError and 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[0].allow_multiple:
raise ValveTypeError(
"Type %s does not allow allow multiple values"
% (type(value[0]))
)
...
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 KeyError and 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.
[edit] 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.
