Raising an error instead of using assert

[heborras]

Hi,

just recently I worked a bit with pyik.
This is more of an improvement than an actual issue.
Looking through the source code I noticed that some functions use assert to verify that an input variable has the correct format. Here, I think raising an error would be more appropriate. An error message can contain the same infos and the error type can be more specific. Additionally: Asserts get turned off when Python is run with the optimization option turned on. As such asserts are okay for testing, but not for sanitizing input variables. Some functions even raise an AssertionError, instead of using assert directly, which I found surprising.

Also this would be a good chance to add further Tests to the current test suit.

And if it's okay, I would like to try to implement this change and submit it as a pull request.

Cheers,
Hendrik

[HDembinski]

I partially agree with you. Your arguments are all fine and known to me. For Boost.Histogram, I thought a lot about when assert or raising an error is more appropriate. In Python, the distinction is a bit blurred, since a failing assert also raises an error.

In my view, when you have a complex library with deep call stacks, asserts should only be used for things that basically should never fail. For things that can conceivably fail from time-to-time, errors should be raised. In particular, failing asserts should be triggered by logical errors in the code path, not by stuff that sometimes goes wrong. A typical example where raising an error is right and asserting is wrong is when your library tries to connect to a server and fails. The appropriate response is raising an error.

But this library is not like that. You typically call a top-level function and get a result. The asserts basically tell you that you used a function wrongly, by violating some pre-condition on the arguments. One purpose of asserts is to check pre-conditions. That's why it makes sense that they are disabled in optimized builds. Asserts guide you during normal development. Once you do an optimized run, your code should not contain logical errors anymore.

For example, centers asserts on the length of the input, which must be larger than 1. Trying to call centers with an array of length 0 or 1 is a logical error. It should not happen in a well-written program. Once you are beyond the development phase, checking this is pretty superfluous. So an assert is appropriate here.