-
Notifications
You must be signed in to change notification settings - Fork 11
Library is using Asserts without throwing a message #21
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
Comments
I disagree. Asserts are good for catching cases that can not sanely occur: programmer error, while exceptions are best suited to things a that go wrong unexpectedly, but for which there is often a way to deal with it: e.g. a communication problem. I.e. Exceptions can be handled, but asserts have no recourse but to cause execution to stop/fail. In this case the assert enforces the contract of the method... gyro_range HAS to be one of those values. If it's something else, the programmer messed up. |
Thanks, valid points. not arguing with that. Taking into account, that I have no problem closing this issue, what would be more helpful to the end user? |
It's really a matter of accepted/encouraged style. But that's what asserts are for. Some people use them, some don't. Using an exception and not handling it does the same job, but obscures the intent. A message is always a good idea. |
Right Thanks.. 👍🏼 |
How does one add a message to an assert in case it happens? If it's not expected to happen then I'd rather remove them. (Remember that asserts use memory.) If they may happen, then an exception with a message would make them more actionable. |
Will do Thanks |
Fix by #23 |
Library is using
assert
statements. It is preferable to add a customary message to inform the problemoutdated:
.instead use.Exceptions
Adafruit_CircuitPython_FXAS21002C/adafruit_fxas21002c.py
Line 83 in 7b68d87
The text was updated successfully, but these errors were encountered: