Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve error messages #299

Closed
mpf82 opened this issue Feb 6, 2023 · 1 comment
Closed

Improve error messages #299

mpf82 opened this issue Feb 6, 2023 · 1 comment
Assignees

Comments

@mpf82
Copy link

mpf82 commented Feb 6, 2023

Is your feature request related to a problem? Please describe.

Error messages could be improved, related issue: #115

Describe the solution you'd like

The actual variable should be part of the error message, where it makes sense.

e.g. instead of raise TypeError("'name' (string) should be from 1-30 chars.")

it could be raise TypeError(f"'name' (string) [{name}] should be from 1-30 chars.") - so the actual name can be seen.

Same goes for other checks, e.g.

TypeError("'field_type' (string) must be in [" + ", ".join(_type2rfc) + "]") -> TypeError(f"'field_type' (string) [{field_type}] must be in [" + ", ".join(_type2rfc) + "]")

TypeError("'direction' (string) must be in [" + ", ".join(_direction2rfc) + "]") -> TypeError(f"'direction' (string) [{direction}] must be in [" + ", ".join(_direction2rfc) + "]")

and so on.

Variables do not neccessarily have to be in square brackets, but I've seen it in print (f"[{datetime.utcnow()} UTC] {origin} '{log_message}'") - plus it helps to figure out if there are leading/trailing spaces in a variable.

@bsrdjan
Copy link
Contributor

bsrdjan commented Feb 10, 2023

Thanks @mpf82 for suggestion, brackets are used for timestamp log only

@bsrdjan bsrdjan self-assigned this Feb 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants