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

[Casey Duncan]

Also, a related recommendation is to only put the parts that could fail i=
n the=20
try: clause. Put the rest in an else clause or after the except: clause. =
That=20
makes it considerably easier to see from reading the code which lines cou=
ld=20
fail and how.

Remember a further evil of bare excepts is that they can catch database=20
ConflictErrors silently before the framework can properly deal with them.=
=20
This is bad since these errors usually only occur in production under loa=
d,=20
so you won't see ill effects in development and testing.

One thing we might leverage is the fact that you can raise any object in=20
Python, not just an Exception object. We could use this to allow you to c=
atch=20
python exceptions, database exceptions, framework exceptions and applicat=
ion=20
exceptions separately for example:

try:

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

Probably the only one that would not subclass Exception would be=20
DatabaseError, so saying except Exception: would actually be useful since=
 it=20
would trap all errors that were exceptions and no others, and modules wou=
ld=20
not need to be dependant on the ZODB directly just to handle exceptions=20
properly. A downside to this would be modules that raise string exception=
s,=20
but thats generally considered bad form anyhow, so screw 'em ;^)

-Casey


On Sunday 10 November 2002 03:32 pm, Steve Alexander wrote:
> Today, I was looking through the code for various placeful services,=20
> with a view to writing my own placeful service.
>=20
> I came across various bare 'except:' clauses in the ErrorReporting Serv=
ice
>=20
> Zope/App/OFS/Services/ErrorReportingService/ErrorReportingService.py
>=20
>=20
http://cvs.zope.org/~checkout~/Zope3/lib/python/Zope/App/OFS/Services/Err=
orReportingService/ErrorReportingService.py?rev=3D1.5&content-type=3Dtext=
/plain
>=20
> The problems with these bare 'except:' clauses are:
>=20
> * They hide errors by consuming all exceptions.
>=20
> * They are hard to correct and replace with specific exceptions, becaus=
e
>    the original author did not explain the rationale for the except
>    clause.
>=20
>=20
> Bare 'except:' clauses caused a number of problems with Zope2. There wa=
s=20
> a very time-consuming purge on them several months ago. I don't want us=
=20
> to have to do the same thing for Zope 3.
>=20
> My recommendations:
>=20
> * Do not use bare 'except:' clauses. Always qualify them with specific
>    exception types.
>=20
> * If you do need to use a bare 'except:' clause, add a comment before i=
t
>    explaining that you used this bare except clause mindfully, and
>    explaining the kinds of exception you need to catch, and the reason
>    the bare 'except:' clause is needed.
>=20
>=20
> Tomorrow I shall check in a change that adds a '# XXX' comment above=20
> each bare 'except:' clause I found. I'd appreciate it if someone who=20
> understands how the code is meant to work can either check in a change=20
> with specific exceptions, or contact me to give me pointers on how to=20
> make the exceptions more specific.
>=20
>=20
> Thanks.
>=20
> --
> Steve Alexander
>=20
>=20
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev
>=20