On Thu, Sep 29, 2005 at 12:53:51 +0200, TSa wrote: > I don't like it at all. I fear, that we mix two orthogonal concepts > just because it is convenient.
"just because it is convenient" is precicely why I like it =)
> To me the statement
>
> return 42; # 1
>
> has to orthogonal meanings:
>
> 1) the current scope has reached its (happy) end
> 2) a specific result was determined
return literally means "give back". The caller is getting a value
that we give. This implies two completely non-orthogonal meanings to
me:
1) the scope has reached its happy end
2) it's reached the end because a specific result was determined
> We can vary on both of these dimensions *independently*!
> Which gives the remaining three cases:
>
> return undef; # 0 unspecific result
just 'return' would do. But This is odd, unless the context is void
- if the caller is expecting something, wer're not returning an
"unspecific result" - we're returning a value. This value is in
bounds (it's a normal perl scalar) and it has a well known meaning
that "i have have nothing meaning to report".
I think this is actually a very concrete result.
> fail undef; # -1 no return with unspecific reason
> fail 42; # -2 no return but determined reason
Fail is, semantically:
(should_die ?? die !! return)
and the caller gets to determine the behavior.
Whether failures have an extras payload in a simple return
value, or whether the payload is carried via an out of bounds route
to the closest thing that can handle is really only dependant on how
the caller is most comfortable with handling errors.
> or in yet another way to describe my attitude: the least
> thing that *defines* an exception is that the dynamic
> scope in question has reached the conclusion that it
> is *not* going to give control back to its creator!
Not at all!
It's simply returning an out of bounds value to the closest caller
that is willing to handle out of bounds values.
In fact, it's short circuiting to it's caller, to give it control as
fast as possible since it doesn't know what to do anymore.
The reason exceptions tend to pop upwards more is that they are
handled in a way that if the immediate caller doesn't know how to
handle it either, it keeps going up the call stack till a calling
scope does know what to do, and can explcititly take control.
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me beats up some cheese: neeyah!!!!!!!!!!!!!!!!!
pgpqFx7QmiXTK.pgp
Description: PGP signature
