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

[Shane Hathaway]

R. David Murray wrote:
> On Mon, 11 Nov 2002, Barry A. Warsaw wrote:
> 
>>But if the three main subsystems you outlined each defined their own
>>base exception class (deriving from Exception), and application code
>>made sure to catch only the derived classes, I think you could largely
>>stil accomplish this goal.
> 
> [....]
> 
>>except DatabaseError: # All ZODB/transactional errors (conflicts, etc)
>>
>>except ZopeError: # All Zope framework exceptions
>>
>>except AppError: # All application defined exceptions
>>
>>except Exception: # All Python exceptions
> 
> 
> But if you trap Exception, you are still trapping DatabaseErrors.
> The goal was to have a way to trap everything (including 'python'
> errors) *except* for DatabaseErrors.  And an enhancedment to
> the except command wouldn't be enough, because what we want
> to do is specify that DatabaseErrors can't be caught by a framework
> that may not be Database-aware.

I see a few options:

1) Don't let DatabaseErrors be so special any more.  Currently, we want 
ConflictErrors to propagate, in order to prevent inconsistent data from 
being committed, and to give the app an opportunity to retry.  But 
excessive exception catching ought not to be so catastrophic.  I think 
any attempt to write or commit after a ConflictError has occurred should 
result in another ConflictError, since the data being written is 
generated from inconsistent data.  AFAICT this would eliminate the need 
to make DatabaseErrors special, and would only change ZODB.

2) Add a subclass of Exception that does not get caught by normal 
"except" clauses.  "SlipperyExceptions" only get caught by exception 
handlers that specifically catch SlipperyExceptions.  This could mess up 
code that uses "except:" where it should be using "finally:".  It would 
require a change to Python.

3) Set a policy that says nothing should ever use bare "except:".  This 
policy breaks up, though, for error reporting and logging.  If an error 
occurs while attempting to display or log an exception with a traceback, 
you really don't want the error to propagate.  You might want it logged 
somewhere.  This would require a change to both past and future 
application code. :-)

Shane