First release of Shed Skin, a Python-to-C++ compiler.

[Robert Kern]

Mark Dufour wrote:

[Brian Quinlan wrote:]
>>You forgot to check for an error when:
>>o when you wrote f.error [attribute "error" might not exist e.g. f is
>>                           None]
>>o you called str(f.error) [might contain unicode characters that can't
>>                            be converted to a string using the default
>>                            encoding]
>>o when you used the % operator [format string might be wrong]
>>And, of course, pretty much every expression can result in a memory error.
> 
> I don't mind the program bailing out in such a case and telling me
> where it went wrong, so I can fix the problem. I just don't really see
> the need for catching exceptions yourself. Especially not in
> well-tested code, potentially to be compiled.

grep the standard library. Tons of use-cases. It really is fundamental
to the way most of us code Python.

>>Exception handling is a boon because almost EVERY expression that you
>>write can result in a error and checking each one is tedious in the
>>extreme. So people forget and then their programs exhibit very odd
>>behavior that is very difficult to debug.
> 
> What do you mean odd behaviour? If they don't catch exceptions, the
> program will bail out, showing what went wrong, yeah?

He was referring to the "error code" method of error handling. People
forget to check the error code (or else wrongly assume that nothing
wrong can happen). Uncaught exceptions *do* make the program bail out at
the point of bogosity (more or less).

>>If you look at the Python C source, you'll notice that probably 50% of
>>the code is devoted to error handling (that was a guess).
> 
> That's a lot of error handling..

It's code that needs to be robust but can't avail itself of exceptions.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter