exception handling in complex Python programs

[Gabriel Genellina]

En Wed, 20 Aug 2008 21:49:14 -0300, dbpokorny at gmail.com <dbpokorny at gmail.com> escribió:

> On Aug 20, 10:59 am, Steven D'Aprano <st... at REMOVE-THIS-
> cybersource.com.au> wrote:
>> Oh goodie. Another programmer who goes out of his way to make it hard for
>> other programmers, by destroying duck-typing.
>
> Remember kids: personal attacks are cruise control for cool.
>
> So this was a simplification - most of the asserts I've written don't
> actually use isinstance, partly because typing isinstance takes too
> long. The point is to create a barricade so that when something goes
> wrong, you get an assertion error against the code you wrote, not an
> exception against doing something like
>
>   print("blah blah %s" % message)
>
> where message turns out to be None. This is simply a way to make
> debugging a more pleasant experience (quite valuable IMHO since
> debugging is inherently difficult and can be quite aggravating). Here
> is a sampling:
>
> assert statelt.tag == 'stat'
> assert len(path) > 0 and path[0] == '/'
> assert self.__expr != None
>
> So here asserts are used to made distinctions that are more fine-
> grained than type.

I think you missed the point. All of those look like program logic verification, and that's fine. But using assert to check user-supplied data is wrong (here "user" may be another programmer if you're developing a library). Assertions may be turned off at runtime.

> If you look at the history of the EAFP concept in Python, then you see
> that it comes from Alex Martelli's Python in a Nutshell around pages
> 113-114. 

Mmm, I think it's older than that.

> I don't think the code examples make the case for EAFP very
> well (not that I know what EAFP is in the first place, given that it
> is barely explained. 

Ok, so you don't know what it is, but dislike it anyway?

> I interpret it as "wrap questionable stuff in try/
> except blocks"), and in any case there is practically no support for
> using EAFP as the dominant error-handling paradigm. 

Uh? I think that using try/except IS the "dominant error-handling paradigm" and that's just EAFP.

> Martelli's posts in support of EAFP are heavily skewed towards a
> multithreaded scenario and avoiding race conditions. IMHO, letting
> locking and race condition concerns dictate your error-handling
> paradigm is a case of the tail wagging the dog, especially when there
> are alternatives to this particular tar pit: pipes or a shared nothing
> architecture.

There are race conditions since multiprogramming existed, around '70, and I'm afraid they'll stay for a long time...

-- 
Gabriel Genellina