[Zope3-dev] Please, no bare 'except:' clauses!

[Shane Hathaway]

Barry A. Warsaw wrote:
>>>>>>"JH" == Jeremy Hylton <jeremy@zope.com> writes:
>>>>>
> 
>     JH> This is sufficient for dealing with sloppy exception handling,
>     JH> though.  If the transaction is read-only and the except clause
>     JH> swallows a ReadConflictError, the app may never find out that
>     JH> a consistency problem occurred.
> 
>     JH> Thinking more... I suppose a Connection could have a
>     JH> per-transaction marker that says it has detected a read
>     JH> conflict.  If the marker is set, it could refuse to load any
>     JH> more objects.  That sounds a bit draconian.  I'm not sure what
>     JH> makes sense.
> 
> Won't multiversion concurrency control eliminate read conflicts?

I thought it would.  The only code that generates read conflicts is 
Connection.setstate(), and AFAIK it would be changed to read from a 
specific transaction or earlier, eliminating the need for that code to 
check for read conflicts.

>     JH> There are very few places where bare except is needed.  At
>     JH> least some of those places, the bare except is in place
>     JH> because it's very hard to tell what exception Python might
>     JH> raise (calling int() is an example).  In cases like that, the
>     JH> StandardError solution is a good one.
> 
> Let's see, int() can raise TypeError and ValueError.  What else?

Anything.

 >>> class m:
...   def __int__(self):
...     return sadf
...
 >>> int(m())
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<stdin>", line 3, in __int__
NameError: global name 'sadf' is not defined

:-)

Shane