Exception handling wart in Python

[Paul Rubin]

"Leo Lipelis" <aeoo at myrealbox.com> writes:
> I'd like some help with an issue I have with Python.  Simply put, I think
> having an exception mechanism is a waste if there is no tool that will let
> you know which unhandled exceptions exist at point foo....
> 
> Considering that in Python exceptions are matched by identity instead of
> equivalence, it's possible to track all the exception flows, right?

Of course not.  Since you can execute arbitrary strings, you can
create new exception classes at runtime and throw them.  

> I agree with whoever said that a race horse doesn't belong in the glue
> factory.  It seems like Python is being used for serious programming, and
> it seems to me, if it supports exceptions, it should support them all the
> way.  It's fairly pointless to provide exceptions if you really never know
> whether you handle all the relevant exceptions or not, without the ugly,
> bad, and stupid except: foo() statements to catch *all* exceptions.

I don't understand the problem.  The whole idea of an exception is
it's something you don't have to know how to deal with.  You catch
the exceptions you can handle, and leave the rest for higher levels
of the program.  You can always catch all the exceptions, and then
if you get something you can't deal with, re-raise it.

> P.S.:  The double leading underscore is the ugliest thing I've ever seen in
> language syntax.  I've been writing some Python code that uses that
> feature, and man, it looks ugly.  For a language that prides itself on
> indentation based code blocks for readability, double underscore is an ugly
> wart that needs to be fixed.  That, and having to constantly type
> self.__quax, self.__foo, self.__bar(), self.__foobar()...  That's
> *SEVEN* whopping useless characters on every line.
>
> P.P.S.: Otherwise Python is a very pleasant and productive language.

Yes, I agree with this, I love Python too.  But just like with any
romantic partner, Python and I sometimes get in quarrels...