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

[Steve Holden]

Mark Dufour 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.
> 
> 
>>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?
> 
> 
>>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..
> 
Mark:

You have achieved so much with the first release of Shed Skin that it's 
strange to see you apparently trying to argue that exceptions aren't 
necessary when in fact they are such a fundamental part of Python's 
philosophy.

Their real value is in removing the necessity to perform explicit error 
checking after each operation in a program. For example, when I write

     try:
         func1(...)
         func2(...)
     except SomeException:
         handle the exception

the authors of func1()) and func2() don't have to worry about explicitly 
  returning control if some condition they can't handle occurs. They 
just write

     raise SomeException

knowing that this will immediately cause all calling contexts to be 
unstacked until the context is reached that is prepared to handle the 
exception.

Without such an ability the logic of the functions tends to look 
something like

     if (errorCondition1):
         return SomeErrorFlag1
     elif (errorCondition2):
         return SomeErrorFlag2
     else:
         perform normal computation
         return Value

and the calling code then has to check for the flags before handling the 
return value.

So basically exceptions allow simplification of program structure with 
more effective and simpler error handling. If you read through (for 
example) the code you'll find in the standard library and you'll get a 
better feel for the usefulness of exceptions.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/