Phillip J. Eby wrote:
> Really, the only use case for suppressing exceptions is to, well, suppress 
> exceptions that are being logged, shown to the user, sent via email, or 
> just plain ignored.  Guido's point, I think, is that these use cases are 
> rare enough (yet simple and similar enough) that they don't deserve support 
> from the cleanup facility, and instead should use a try/except block.

Particularly since the *action* can be factored out into a do statement - it's 
only the *suppression* that has to be reproduced inline. That is:

   try:
       do standard_reaction():
           pass
   except MyException:
       pass

> After reviewing the cases in my own code where I might've used a 'with 
> logged_exceptions()' or similar blocks, I think I now agree.

I think I'm convinced, too. The only actual use case in the PEP is auto_retry, 
and that can be more obviously written with a try/except block inside the loop:

   for retry in reversed(xrange(num_attempts)):
       try:
          make_attempt()
          break
       except IOError:
          if not retry:
              raise

Not as pretty perhaps, but the control flow is far easier to see.

Steven has also convinced me that break, continue and return should look like 
normal exits rather than exceptions. This should bring my next PEP draft back 
to 
something resembling Guido's option 3 - the __exit__() method still gets passed 
the contents of sys.exc_info(), it just can't do anything about it other than 
raise a different exception.

Cheers,
Nick.

P.S. The points regarding non-local flow control in Joel Spolsky's latest Joel 
on Software article (especially the links at the end) may have had something to 
do with my change of heart. . .


-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to