On Fri, 2011-10-07 at 15:18 -0400, Jim Jewett wrote:
On Thu, Oct 6, 2011 at 6:04 PM, Terry Reedy firstname.lastname@example.org wrote:
On 10/6/2011 4:32 PM, Jim Jewett wrote:
On Wed, Oct 5, 2011 at 5:17 PM, Terry Reedytjreedy@udel.edu
On 10/4/2011 10:21 PM, Guido van Rossum wrote:
We also have str.index which raised an exception, but people
writing try/except blocks.
... try/except blocks are routinely used for flow control in
... even advocate using them over if/else (leap first)
str.index is a "little" method that it is tempting to use inline,
as part of a comprehension.
That is an argument *for* raising an exception on error.
Only for something that is truly an unexpected error. Bad or missing data should not prevent the program from processing what it can.
When I want an inline catch, it always meets the following criteria:
(a) The "exception" is actually expected, at least occasionally.
Sometime I feel exceptions are overly general. Ok, so I got a ValueError exception from some block of code... But is it the one I expected, or is it one from a routine in a library I imported and wasn't caught or handled correctly. (ie.. my routine called a function in another module someone else wrote.)
One answer to that is to put the try except around the fewest lines of code possible so that it doesn't catch exceptions that aren't related to some specific condition. That leads to possibly quite a few more try-except blocks, and possibly more nested try-except blocks. At some point, it may start to seem like it's a better idea to avoid them rather than use them.
What if you can catch an exception specifically from a particular function or method, but let other unexpected "like" exceptions bubble through...
try: ... i = s.index('bar') ... except ValueError from s.index as exc: <handle s.index ValueError>
In this case, the only ValueError the except will catch is one originating in s.index.
So instead of creating more exception types to handle ever increasing circumstances, we increase the ability to detect them depending on the context.
So then I can put a larger block of code inside a try-except and put as many excepts on after the try block to detect various exceptions of the same type, (or different types), raised from possibly different sub parts within that block of code. And if need be, let them bubble out, or handle them.
Just a thought...