Error classification

I’d like to start a discussion about everything that comes with errors. At the moment we have only one type of error - DataError, which is when something is invalid. The problem I see here is when you want to give any extra details about what gone wrong, you can’t.

In my application I’ve come up across this issue and the only way I could deal with it is something like this:

from enum import Enum


class ErrorCode(Enum):
    required = 'required'
    too_big = 'too_big'
    too_short = 'too_short'
    invalid = 'invalid'

def make_code(text: str) -> ErrorCode:
    if text == 'is required':
        return ErrorCode.required

    if any(phrase in text for phrase in ('long', 'is greater', 'should be less', 'too many')):
        return ErrorCode.too_big

    if any(phrase in text for phrase in ('short', 'is less', 'should be greater')):
        return ErrorCode.too_short

    return ErrorCode.invalid

error: trafaret.DataError
# some logic to get an error
error_code = make_code(error.error)

This is ugly and absolutely not reliable. Trafarets tend to have different messages describing such cases, and next time I’m gonna add a trafaret I’m not using just yet, I can’t be sure it works like expected. Not speaking about custom extensions…

In my opinion there should be internal error classification and all the trafarets we have so far should stick to it. And honestly, I think we need to drop error messages too because really they’re out of scope of this library, it is simply too much specific context that generally lives on app level. Such system also has to be extendable for specific cases when trafaret’s basics aren’t enough. I mean you should be able to easily make your own error types and use them inside library ecosystem, not around it.

First approach I’d like to consider is introduce some classes like generic InvalidError along with more specific RequiredError, TooBigError and so on, which all subclass DataError. Also it would be handy to add some shortcuts for Trafaret class as well. And maybe deal with OnError trafaret in some way to go along with the changes?

I’m willing to make a pull request with those improvements, but of course we have to come to terms first about how it should be done. What do you think?

[ave-satan]

I agree on what @asvetlov is talking about.

Rather than doing something like this:

import trafaret as t

try:
    t.Int(gt=5, lt=10).check(some_var)
except t.TooShortError:
    message = 'not big enough'
except t.TooBigError:
    message = 'way too big'
except t.InvalidTypeError:
    message = 'expecting an integer'
except t.DataError:  # all other errors I don't care about
    message = 'invalid value'

I would prefer this way:

import trafaret as t

errors = {
    'too_short': 'not big enough',
    'too_big': 'way too big'
}

try:
    t.Int(gt=5, lt=10).check(some_var)
except t.DataError as exc:
    message = errors.get(exc.code, 'invalid value')

It is much less hassle to deal with codes rather than specific exceptions. I can hardly imagine someone needs those, can you? Making subclasses for different types of errors assumes you need to handle those errors in different ways. But in reality you don’t. All this lib is about is checking whether you can go with the data provided or not, at least in my point of view.

So if it’s not the case, I’m going only for codes.

[Deepwalker]

Exact JSON schema is up to you, it will not be a part of trafaret. So I vote for exceptions codes and hierarchy. And probably we will need to modify OnError to be able to raise particular exception and code in addition to message.