Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Error classification

See original GitHub issue

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?

Issue Analytics

  • State:open
  • Created 5 years ago
  • Comments:13 (8 by maintainers)

github_iconTop GitHub Comments

ave-satancommented, May 16, 2018

I agree on what @asvetlov is talking about.

Rather than doing something like this:

import trafaret as t

    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'

    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.

Deepwalkercommented, May 16, 2018

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Classification of Errors - Web Formulas
Classification of Errors: Errors are classified in two types – Systemic (Determinate) and Random (Indeterminate) errors. Systemic (Determinate) errors:
Read more >
Classification Error - an overview | ScienceDirect Topics
The estimation of the classification error probability presupposes that one has decided upon the data set to which the error counting will be...
Read more >
Chapter 17 Classification error | Stats for Data Science
The nomenclature signals that a mistake has been made with the word “false.” The kind of mistake is either “positive” or “negative”, corresponding...
Read more >
Classification Error Definition | Law Insider
Classification Error means as to Signing Classification Errors, an incorrect classification of a Priced Life or a Priced Life's benefits as to be...
Read more >
Table 6: Categories of Medication Error Classification
Category Description Example A No error, capacity to cause error NA B Error that did not reach the patient NA I Error that could have resulted...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found