[Zope-dev] Greedy except clauses

[Anthony Baxter]

I took the list I generated, and started looking at a number of them.
There seems to be a number of different types of case:

There's the "just too slack to specify the exception" case --
generally easy, if tedious, to fix.
There's the "we're rendering DTML, it could raise an exception
of some sort, let's just eat it" -- this is almost certainly
the worst sort.
Then there's the 'gods only know what this is for' ones -- I 
think these might best be approached by putting a logging
statement in the except body just to get an idea of what
they're doing.

There's certainly ones that are exceptions around too many lines,
when it's obviously just meant to catch the one line.

I just realised the list I put up has a few that are wrong, for
some reason - my simple-minded script was obviously too simple-minded -
will fix.

(hm, in the case where a bare except _is_ genuinely what's wanted, 
could we put a comment in the source to make it easier to strip 
them out).

Anthony, working towards an "except:" free-world :)

>>> Jeremy Hylton wrote
> >>>>> "AB" == Anthony Baxter <anthony@interlink.com.au> writes:
> 
>   AB> Now, it's obvious that not all of these are bad - some are
>   AB> probably fine - but there's also many that are _not_ good. The
>   AB> one in MailHost.py does eat exceptions. I'm sure there are
>   AB> others.
> 
> I am probably a bit idiosyncratic, but I prefer to avoid bare excepts
> at all costs.  I often use "except Exception:", otherwise I add a
> comment that specifically notes that I intend to catch everything.
> Otherwise, you can't tell the difference between intentional and
> accidental use.
> 
>   AB> I've done a quickie hack script that runs over the source and
>   AB> produces a list of matches to lines in the file, and links to a
>   AB> lightly patched viewcvs so that you can jump straight to the
>   AB> lines. It seems like it would be reasonably easy to make this a
>   AB> bit more sophisticated to include things like the nesting 'def'
>   AB> and 'class' method.
> 
>   AB> This, to me, seems like a pretty nice community type task -
>   AB> people could take one of them off the list of unchecked ones,
>   AB> and have a look through the code... no?
> 
> It would also be interesting to see how many try/except blocks are
> including more code than they should.  The larger the block, the more
> likely that a line of code raises an error that the author didn't
> consider; these errors can mean that real bugs get caught be accident
> and ignore.  When the block is small -- preferably just a line or two
> -- there is litle chance for error.  Of course, there are very good
> reasons to have longer except blocks.
> 
> Jeremy
> 

-- 
Anthony Baxter     <anthony@interlink.com.au>   
It's never too late to have a happy childhood.