Is this the *right* way of exception handling?

[Quinn Dunkan]

On Fri, 03 Aug 2001 17:18:31 -0700, Erik Max Francis <max at alcyone.com> wrote:
>Quinn Dunkan wrote:
>
>> Unfortunately, python's
>> assertion mechanism is not well integrated with the exception
>> mechanism, so
>> assertions that should really raise a ValueError will always raise an
>> AssertionError.  A possible third argument to 'assert'?
>
>Are you suggesting some kind of difference between logic asserts (logic
>faults) and data asserts (bad data, has to be handled properly)?  In
>Python, the latter should definitely not be presented as asserts, but
>rather as just raising some other (possibly custom) exception.  Logic
>asserts mean something's broken; data asserts just means someone sent it
>bad input data and need to be handled properly by the program in any
>case.

I'm suggesting that an assertion can assert many things.  It can assert a
class invariant, or a proper value, or the consistency of data on disk.  But
these are all flattened into a generic "AssertionError".

Python provides two ways to do the same thing:

if not foo: raise bar

and

assert foo

The difference is that asserts can be turned off.  I use asserts to describe
sanity checks which are redundant and unnecessary in a working program, and
'raise' for everything else.

I don't think your logic and data asserts dichotomy makes much sense, since
logic faults are usually manifested as bad data.  If someone sent you bad
data, it either came from the outside world, in which case you have to deal
with it, or it came from your program, in which case it's a bug.  And at a
certain programmer and program defined point, it's a bug if data from the
outside world hasn't been checked for errors.

Python style is often to just toss the data in, and see if it's good by
whether it blows up or not (the "better to ask forgiveness" philosophy), but
it can be handy to catch things before that point, especially when the
consistency of a filesystem or database is at stake.  And sometimes those
checks can be very expensive, so it's handy to be able to turn them off when
everything's been tested.

On the other hand, if it's a "bug" error, you usually shouldn't be catching
it, so it shouldn't be an ordinary exception type.  I dunno.  In any case, I'm
happy the way things are and don't want yet another little convenient feature.
I can still write "if __debug__: if foo: raise bar", but hardly ever do.

So I take it all back :)

Yeah, it has to be decided by the programmer.  Some bad arguments can be
caused 
contract violations are the result of 

>
>-- 
> Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
> __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
>/  \ The basis of optimism is sheer terror.
>\__/ Oscar Wilde
>    Rules for Buh / http://www.alcyone.com/max/projects/cards/buh.html
> The official rules to the betting card game, Buh.