remove assert statement (Was: Re: PEP new assert idiom)

John Roth newsgroups at jhrothjr.com
Sun Nov 7 22:41:28 EST 2004


"Paul Rubin" <http://phr.cx@NOSPAM.invalid> wrote in message 
news:7xhdo1pk1u.fsf at ruckus.brouhaha.com...
> "John Roth" <newsgroups at jhrothjr.com> writes:
>> I see assert as a statement of an invariant: each and every time
>> I come here this *must* be true.
>
> Yes, that was the intention of the assert statement.  However, there's
> a very great temptation to use it for a somewhat different purpose,
> namely checking data validity.  When there's a great temptation to
> misuse some feature to do X when it's really intended for Y, that's a
> sign that it's time to add an equally convenient feature intended for
> doing X.
>
>> For me, an assert failing is a programing error in the caller, not
>> in the method with the assert!  Trying to catch an assert is a misuse
>> of what the statement provides.
>
> There's a slight non-sequitur there.  Every large system contains
> programming errors, and assert statements are a good way to detect the
> errors.  If an assert fails and isn't caught, the system crashes.
> Crashing a running system on detection of the slightest programming
> error is not always an acceptable thing to do.  Sometimes you have to
> log the error and try to recover from it, disable the feature where
> the error happened until someone can figure out what went wrong, or
> whatever; but not crash.  So you need to be able to catch assert
> failures.

I think I didn't say it quite well enough. Of course you catch
assert errors, but you classify them the same as non-recoverable
environmental errors: you scrub whatever unit of work you were
working on, log the error and try to recover the application so
the user can continue.

I think we're in agreement that what you don't want to do
is try to catch and recover from a specific assert error.

John Roth 




More information about the Python-list mailing list