On 13May2020 16:20, chris.the.developer.0@gmail.com
I'm working with developers that have decided to use asserts every time they want to throw an exception.
Since asserts are disabled when the optimiser is activated, I'd say these devs don't speak Python. Also, AssertionErrors are a pretty vague way to raise an exception, and there's a whole suite of exceptions available.
I feel that their should be something that dissuades this behavior in the language design.
Bad code can be written in any language, of any design. You would FAR better off finding out _why_ they want to use this approach, since the language documentation makes it clear that asserts may have NO EFFECT AT RUNTIME, depending on the mode. The only thing I can think of for this is that: assert x > 0 is much more concise than: if x <= 0: raise ValueError("x should be > 0, got %s" % x)
This could be making asserts not recoverable, making it so you can't stop assert failures from printing to stdout, forcing the return code to -1 on process termination if an assert fails, or something else.
Making asserts inflexible, in a complete lack of consistency with every
other exception type, seems very artificial. You'lll just push the devs
from misusing asserts to misusing something else.
_Are_ your devs catching AssertionError and preventing programme
termination?
Cheers,
Cameron Simpson