Exception handling wart in Python

[Leo Lipelis]

On Thu, 01 Nov 2001 19:27:47 -0500, Chris Liechti wrote:

> "Leo Lipelis" <aeoo at myrealbox.com> wrote in
> news:pan.2001.11.01.19.35.44.23.979 at myrealbox.com:
> 
>> Hi Pythoneers,
>> 
>> 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.  I
>> have spoken about this issue briefly with Neal, of the PyChecker fame,
>> and he seemed to agree with me.
>> 
>> I realize that it's a difficult problem to solve, but I think it would
>> be worth solving at the language level, similarly to the way it's done
>> in Java.
> 
> on the other hand java has "Errors" which are thrown/raised like
> exceptions but those are not enumerated in a "throws" statement. you'll
> always find cases where you don't know which exceptions could be thrown
> in a method (think of dynamicaly created methods, remote objects,...)
> and python is a very dynamic language.

But it's important and valuable that Java does let you know about *most* of
the exceptions you are likely to encounter.  This is not an "all or
nothing" thing, is it?  I hope not.  If some tool can give me any help with
exceptions, then I will take it; that's my position.  It's infinitely
better than reading the docs for a list of exceptions "I might want to
handle".  As I said before, such a mundane and thankless task needs to be
handled by a computer program.

> 
> ..
>> I think relying on documentation for this is not an option.  First,
>> there is never a guarantee of documentation, and I would like this
>> feature to be guaranteed.  Second, it becomes very problematic with
>> deeply nested functions and inheritance.  Why should I have to search
>> through all those docs for something that compiler should tell me
>> anyway?  This is just the kind of monotonous task that needs to be done
>> by a computer program instead of a human.
> 
> most of the arguments for dynamic typing apply to to the exceptions too.
> return types are only in the documentation, parameter types too if you
> want to be sure you have to consult the docs anyway (and the sources
> aswell, as docs aren't allways up to date). if you don't trust python's
> dynamic typing stay to a staticaly typed language like java.

I don't have a problem with dynamic typing.  Types can be inferred anyway.
They don't have to be declared.  But this is not the point.  The issue is
that a good tool can warn you about 99% of all exceptions you are likely to
encounter.  Is such a tool valuable?  It is to me.  I would use it all the
time.  Most of the time you are dealing with exceptions that are *not*
dynamically declared.  Most of the time, you know well ahead of time that
so and so code will throw so and so exception.  For example, a piece of
networking code can throw "ConnectionException" or some such, because it
would be very normal to encounter connectivity problems.  Should you
dynamically create a random exception and throw it just because the
language will let you?  I think not.  You only throw what makes sense, and
in most cases, you will know well ahead of time what exceptions you will be
throwing.  It's a very *rare* case where you really do *not* know what
exception you will throw, but even then, you will at least know what class
of exceptions they will belong to.

> 
> ..
>> 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.
> 
> nice and useful "except:", especially if you need a program that runs
> unatended for months ;-)

A program that runs unattended for months is not necessarily a good or
useful program ;).

10 goto 10

> 
> 
>> Leo "__who_doesnt_like_underscores_and_many_selves_at_all__" Lipelis
>> 
>> 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.
> 
> "private" is 7 characters per method decalration too in java (and then

Bah, you don't type "private" on every line.  On the other hand, I have
Python methods where I have "self.__" mentioned 2 or 3 times per line.
It's ugly.  It's breaks the DRY (don't repeat yourself) concept.

Besides, let's not compare to another language with even more problems and
say, but they are worse, thus we don't need to improve :).  Who cares if
Java is too verbose?  Point is, Python can be made better by getting rid of
the "self.__" in front of every object attribute.  For instance, why not
assume that ALL variables are instance variables, and have the other ones
use some special notation?  The absolute majority of attributes you will
use are instance attributes.  Why penalize the common case?  That's bad
engineering.  You should always penalize the fringe case.  Doesn't that
make sense to you?  If you have 2 class attributes and 20 instance
attributes, why would you penalize the 20 instead of 2?  That's insane.

> the return type, parameter types, throws... ";{}" every now and then, no
> thanks, i want to write functionality, code that does something and not
> zillions of characters just to get the compiler happy)

Same here!  I think Python is mostly very good about that.  But the double
underscore is a bad hack.  It's not elegant or brief or intuitive.  When
you actually *use it a lot* it really grows old fast.  It seems like a
feature invented by someone who never actually uses it much.

> 
> and python has the advantage that i see that a method is private when i
> read the call. in java you have to consult the object documentation or
> scroll around just to see if a method is private, (or private, publ..
> etc). a win for python

In Java you don't even know anything about private methods.  You wouldn't
even be SEEING the calls in the first place, because in Java the classes
are black boxes.  The only thing you will see are calls to protected and
public methods.  And javadoc or even better ctags+vi will tell you *really
fast* and *reliably* what you're calling.  So even if it's a win for
Python, it's a very mild one and not enough of a win to justify the double
leading underscore plus "self." on every single variable and function.

> 
> writing "self" explicitly is important for a distiction for object
> attributes and global variables. (ever tried to explain "this" (and
> "super") and that its optional sometimes to a java beginner?)

Ok, this is a good point.  But now Python goes much further than just the
teaching language it used to be.  Python should serve the professionals
too.  Isn't there a good solution that works well for both?  Why make
something that *only* works well for newbies, but becomes a heavy burden
for pros?