Error classification
See original GitHub issueI’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?
Issue Analytics
- State:
- Created 5 years ago
- Comments:13 (8 by maintainers)
I agree on what @asvetlov is talking about.
Rather than doing something like this:
I would prefer this way:
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.
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.