2
\$\begingroup\$

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:

Github Permalink

"""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:

Permalink

if not datatype in self.datatypes:
    raise ValveKeyError(
        "Unknown datatype [ %s ]"
        % datatype
    )
...

Permalink

if not hasattr(self, vmf_key):
    raise ValveKeyError(
        'Key `%s` not allowed in %s'
        % (key, self._type())
    )
...

Permalink

if not value[0].allow_multiple:
    raise ValveTypeError(
        "Type %s does not allow allow multiple values"
        % (type(value[0]))
    )
...

Permalink

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:

Permalink

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.

\$\endgroup\$

closed as off-topic by vnp, Mast, Graipher, IEatBagels, AJNeufeld Dec 9 '18 at 16:39

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – vnp, Mast, Graipher, IEatBagels, AJNeufeld
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    \$\begingroup\$ Well, exception classes all by themselves don't mean much. Where do you throw them? Under what circumstances? Please add enough context for reviewers to actually be able to review your code - as for the permalink, please see this meta post. \$\endgroup\$ – Mathieu Guindon Feb 1 '15 at 23:34