Python and Flaming Thunder

[Dan Upton]

On Thu, May 29, 2008 at 3:36 AM, Duncan Booth
<duncan.booth at invalid.invalid> wrote:
> Dave Parker <daveparker at flamingthunder.com> wrote:
>
>> Catch doesn't return just error types or numbers, it can return any
>> object returned by the statements that are being caught; catch doesn't
>> care what type they are.  For example:
>>
>>   Writeline catch(set x to "hello world".).
>>
>> will write "hello world".
>
> I really don't get this. Surely the point about an error being thrown to a
> catch statement is that the error path is separate from the normal
> execution path? What you are doing here is ensuring that unexpected errors
> have no chance at all of propagating up to the top level: they are
> invariably going to get caught by some other handler that was installed
> just because someone was too lazy to write a set statement followed by a
> writeline.

It also looks like an overloading of catch, semantically similar to the C:

int retcode;
if( retcode = doSomethingThatReturns0or1() ) printf("Hello world");

Again, I don't think you want to start overloading your
exception-handling mechanism.  If you want a set expression to be
equal to the l-value at the end, that's fine, but there's no reason
that catch should evaluate to an object or an integral- or real-valued
exception in error cases, or of the last statement of the block if
there's no error.  (Evaluating a block to be equal to its last
statement is okay, I guess; I know at least that there's a call in
Scheme that lets you do a more imperative programming style in the
functional language--whether that's a good thing is probably a holy
war.)  I just think if you're shooting for an easily understandable
language, overloading error handling requires more thought on the
programmer's part, not less, because they have to reason about all
outcomes.