Why assert is not a function?

[Richard Damon]

On 3/12/21 8:58 AM, Chris Angelico wrote:
> On Sat, Mar 13, 2021 at 12:11 AM Richard Damon <Richard at damon-family.org> wrote:
>> On 3/12/21 12:31 AM, Chris Angelico wrote:
>>> On Fri, Mar 12, 2021 at 3:53 PM Cameron Simpson <cs at cskk.id.au> wrote:
>>>> For me, try/except is for when something might reasonably "go wrong" in
>>>> normal use, even niche normal use. Whereas assert is for things which
>>>> should _never_ occur. Roughly, again for me, try/except if for catching
>>>> misuse and assert is for catching misdesign/misimplementation.
>>> Something like that, yeah. An assertion failure represents a bug *in
>>> this code*, something that shouldn't ever happen. If it's possible to
>>> trigger the failure with some other piece of code (calling something
>>> with bad arguments, or whatever), then assert is the wrong tool for
>>> the job. Similarly, if you find yourself catching AssertionError
>>> anywhere outside of unit testing, something is horribly wrong
>>> somewhere :)
>>>
>>> ChrisA
>> Chris, I would disagree with that statement. An assert says that there
>> is something wrong with THE code, not THIS code. It is perfectly
>> reasonable, and good defensive programming, to assert on the
>> per-conditions to the procedure at its beginning.
>>
>> Now, it may be true that a 'friendlier' procedure may be defined to
>> check some of these and return an error, but that then locks that
>> behavior into the API, so the cost of the check becomes an absolute
>> requirement.
>>
> It's perfectly reasonable to put "if condition: raise Blah", but is it
> really reasonable to use the assert statement, which (a) might not be
> run, and (b) raises a very generic exception? Make assertions about
> your own code, not other people's.
>
> ChrisA

My issue with that is that I feel that if the program raises an
exception, if SHOULD document what exceptions it raises and under what
conditions. That means that the detection of bad parameters has now been
moved from being an 'improper' use of the module, to being defined to be
checked for, and thus now a required part of the API.

Exceptions are designed for errors that might be correctable by outer
layers, program errors that you catch with assert tend not to fall into
that category.

Asserts indicate that there is a programming error that has been
detected, and the operation should be aborted. The exception generated
will not be used to 'correct' the error, but might reformat the assert
message and facilitate its reporting, or for an interactive program,
perhaps provide a path for the user to save his work or work around the
program bug.

The are conceptually very different sorts of things, and should not be
interchanged.

Note, it is often hard to tell if the 'impossible' state you ended up in
is truly a fault with your own code or the code that is calling you, so
often the detecting of bad parameters is really akin to detecting your
routine has gotten into a state it should not be in, the only difference
is you have detected this before you have done anything, and thus help
locate where the bug is.

-- 
Richard Damon