Exception handling wart in Python

[Chris Liechti]

"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.

... 
> 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 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 ;-)

> 
> 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 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)

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

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?)


> 
> P.P.S.: Otherwise Python is a very pleasant and productive language.
absolutely agreed

chris 


-- 
Chris <cliechti at gmx.net>