Exception handling wart in Python

[Steve Holden]

"Leo Lipelis" <aeoo at myspamrealbox.com> wrote ...
[...]
> This is also nonsense.  Sure you can catch all exceptions and examine
them.
> But in order to code anything intelligent, you again have to know ahead of
> time what these exceptions might be.  At the very *LEAST* you need a list
> of *all possible* exceptions in an entire Python code base, including
> Python standard module library!  But how much better would it be if you
> could narrow the scope to the most likely exceptions.
>
Presumably all Python written to date is therefore "non-intelligent"? Sounds
to me like you've got a project on your hands. Unless you're just bitching
about this because you think somebody else will "fix" it if you make enough
noise.

Unfortunately (for you) the Python community is made up largely of
pragmatists. Even if you could convince them that this is a major wart, the
response will likely be "Yeah, I suppose it is" followed by a return to
coding. The language isn't broken, it's MEANT to be like this.

> except: # foo is not bound here... because I am catching ALL exceptions
>     if (not self.__canHandleException(foo)): # what is foo?
>         raise foo # and how can you re-raise it here?  what is foo?
>
Technically, "foo" is a euphemism for "fu", meaning "fucked up". But this
being Python, you should really be using "spam", "eggs" or "chips". Erm,
sorry about the wilful misunderstanding: I think you are groping for

    raise

here. See below ...
> ...
>
> def __canHandleException(foo):
>     if type(foo) == BlahType: # ahh, but you have to know about BlahType!
>         return 1
>     elif type(foo) == BuzType: # again, you have to know about BuzType!
>         return 1
>     elif type(foo) == OtherType: # and how do you know about OtherType?
>         return 1
>     else:
>         return 0
>
> The above is not very smart and in fact, I don't even know how to
reference
> the exception object when you use catch-all "except:".  Even if it can be
> done, it doesn't accomplish anything.
>
Well I suppose something needs changing if you don't know how to reference
the exception object. Probably your understanding :-) ... I agree the above
isn't smart, but there is absolutely no need for it. You appear to be
complaining, at least in part, about some language which we might call
"partial Python". RTFM?

> I'd much rather read this:
>
> except BlahType:
>     self.__handleBlahError()
> except BuzType:
>     self.__handleBuzError()
> except OtherType:
>     self.__handleOtherError()
>
> But, no matter how you write it, you *still have to know* what exceptions
> you need to handle.  You can't magically decide it at run time, nor do you
> need to, nor should you.
>
The Pydiom you are struggling for, already mentioned but not spelled out by
another poster, appears to be

except BlahType:
    self.__handleBlahError()
except BuzType:
    self.__handleBuzError()
except:
    raise # can't handle this one, sorry

The assumption here is that unknown/unexpected errors will be handled by a
higher level. If they aren't, then ... crapola, your program breaks. Shit
happens.

> The dynamic nature of Python is absolutely not a reason for such a
> lucklaster handling of exceptions in Python.  Let's get this argument out
> of the way, because I don't think it's even worth discussing further,
> unless someone can demonstrate that in 99.99% of cases you really can't
> possibly know what exceptions you should handle anyway.  Again, just
> because it's possible to use the language in a twisted way, doesn't mean
> that the other 99.99% of exceptions should be penalized by not having a
> tool that automatically warns you about unhandled exceptions.
>
So write the tool. Frankly I don't want to be told about all the unpleasant
things I already know the real world can do to me but usually won't. Perhaps
this makes me an optimist?

> The very uncommon case where someone decides to create and throw random
> exceptions, just for fun, should not be protected or used as an excuse to
> deny us the very useful service of warning about unhandled exceptions.
Nor
> should this excuse be used to diminish the importance of such a tool.  I
> say that without such a tool, exceptions in Python are pointless at worst,
> and are very awkward to use at best.  Documentation is *not* the answer,
> and I already explained why not in my original post.

So, basically, you seem to be saying that Python is a fine language, but it
won't be usable until someone retrofits an equivalent to Java's "throws"
clause. Looks like horseshit, smells like horseshit, this must be ...
horseshit! Python is what Python is, and nobody is trying to force it down
your throat. To come whingeing to the newsgroup because it isn't enough like
Java seems infantile.

Ultimately you appear to want no program to ever be able to fail in an ugly
way, barfing over the console, and you are prepared to force programmers to
work at handling low-probability exceptions to achieve this end. As has
already been pointed out, you can always take existing code and wrap it in a
catch-all:

try:
    ### "nasty" program
except:
    print "Oh dear, the Universe just exploded"

The next thing you know the "exception police" will be stopping us from
writing

    print open("anyoldfile.txt", "r").read()

because open can raise several exceptions which this statement fails to
handle. Yup, that's horseshit all right. Just as a matter of interest, what
would be your "approved" alternative for the above one-liner? Sorry if my
response comes off as aggressive, which isn't in the spirit of this
newsgroup. I'm actually trying to teach you something here!

didn't-realise-i-cared-so-much-ly y'rs  - steve
--
http://www.holdenweb.com/