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/
--
http://mail.python.org/mailman/listinfo/python-list
