I love assert

[Albert van der Horst]

In article <87a93tl07u.fsf at elektro.pacujo.net>,
Marko Rauhamaa  <marko at pacujo.net> wrote:
>Chris Angelico <rosuav at gmail.com>:
>
>> On Sat, Nov 15, 2014 at 11:12 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>>> Most importantly, assertion failures are not supposed to be recovered
>>> from (within the program). Assertion failures can result in the loss
>>> of life and limb. They can result in database corruption. They can
>>> result in monetary losses. They can result in smoke coming out of the
>>> monitor.
>>
>> Or, in theory, AssertionError just prevented any of the above from
>> happening.
>
>I'd advice against catching AssertionError and trying to recover from it
>within the program. You could catch it, log it and reraise it, but since
>the failure modes could be completely unexpected (really, by
>definition), I would move fault-tolerance outside the failing process
>and try to restore a coherent reality from there.
>
>Assertion errors are in the same class with CPython bugs, external
>signals (say, SIGKILL), security breaches, hardware failures and the
>like.
>
>For expected failure modes, other exceptions are a suitable facility.

I agree with you (also with your other posts) and I hate that disabling
asserts is considered a kind of "optimising".
Wasn't Dijkstra who said that while the ship is on the dock, we have
life vests on, and while we are at sea, the life vests stay on shore.

It is a defect in python that asserts are automatically removed with
a -O option. Maybe if there are six levels of optimization -O7 at
last would remove the asserts.
Then in the programmers manual of my company I would have:
"Programs are only allowed to use -O7 if there is a test that doing
so results in a substantial benefit in running time, and documented
as such."

And no: AssertionError is no exception to be thrown (such that an
irresponsible person might catch, or even ignore them.)

Indeed it should be treated like a parity fault in the memory of
a computer: don't drive because the brakes don't work.

And then Ben Finney wants us to remove the asserts as soon as
they are committed to source control. Please! It is a fallacy that
there are untested and tested, hence correct, programs.
There are just more or less tested, and more or less correct
programs.
If I deliver a program to source control it may not be solid.
If I give it a tag it is solid... until the company sets a junior
on it to add a feature. Then the assert may turn out to be
life saver, even literally.

>Marko
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert at spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst