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.