"Dan Upton" <[EMAIL PROTECTED]> wrote:
> On Thu, May 29, 2008 at 3:36 AM, Duncan Booth
><[EMAIL PROTECTED]> wrote:
>> Dave Parker <[EMAIL PROTECTED]> 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.
>
I like BCPL's way of handling block expressions: VALOF is followed by a
block of statements and within that block RESULTIS gives the result.
This lets you exit the block early (just like a return statement does),
but without returning from the current procedure (unless of course the
entire body of the procedure is a VALOF block). Naturally the result has
to be explicitly specified (otherwise the value is undefined).
Maybe FT should do something similar:
Writeline value of (set x to "hello world". Result is x.).
and catch can then stick to catching errors.
--
Duncan Booth http://kupuguy.blogspot.com
--
http://mail.python.org/mailman/listinfo/python-list
