Better errors
steamraven opened this issue · 2 comments
Asserts may not be the best to catch length mismatches.
Maybe:
Convert length errors to ValueErrors
_raise_on_error raise a more specific error (like SodiumError?)
Possibly a special error for open and verify failures
@steamraven To be honest, I did not give much of a thought on this when I did it and I'm still not sure what is better.
I may be influenced by the C++ world where I started but I've always used assertions to signal programmer errors. Now I understand that even the Python standard library raises ValueError or TypeError on programmer errors so it might just not be a good idea to do otherwise.
Do you think going with ValueError is more Pythonic ? If so, I have no problem changing that.
I think there are several types of errors.
Input validation errors: these are from incorrect length. I think these should be ValueError
Libsodium errors: since most libsodium functions are fairly simple an error result would mean something very broken. Probably not recoverable. I think systemerror or runtimeerror or a custom exception would be appropriate
Libsodium Resource errors: there are a few libsodium functions that rely on external resources: secure memory functions and random generators. I think we can fold them into the above section
Open/verify errors: these could easily happen in a correct program. However, it is a symptom of something wrong. I think either return None/False or raise a different custom exception