Rasmus,
I think you're missing the difference here. Let's look at an exception.
try {
doFoo();
throwsException();
doBar();
} catch (Exception $e) {
doBaz();
}
This is NOT the same as:
doFoo();
throwsException('doBaz');
doBar();
To emulate the exception using continuation passing, you'd need to
pass two functions, a success and a failure.
doFoo();
throwsException('doBaz', 'doBar');
And that's for a single stack level. Imagine how complicated it would
become if you were dealing with a large stack or multiple throwers.
You'd have something like this:
doFoo();
throwsException1(function() {
throwsException2(function() {
doBar();
},
function() {
throwsException3(function() {
doBaz();
},
function() {
doBiz();
}
});
}
It'll get really messy really quick.
As far as your point about keeping multiple stacks, imagine this code:
try {
throwsInterrupt();
doSomething();
} catch (Interrupt $i) {
callFuncThatInternallyCallsAnotherThatThrowsInterrup();
resume;
}
Now, you have 3 independent stacks that are raised. The one for the
original call to throwsInterrupt, one for the function that internally
calls another that throws, and one for the internal interrupt itself.
All three would need to be detached at some point from the execution
stack and saved for resume. So you're not only unwinding the stacks,
but saving them as well incase the interrupt is resumed (to re-wind
the stack).
Right now, Exceptions don't have this problem, since the stack is
never rewound. So it only grows or is unwound based on the exception
tree...
Not to mention that code execution is always linear in an exception
case. It's not possible that code flow will magically jump around.
Sure, you could emulate it with goto (
http://codepad.viper-7.com/i3Dhv4 ). But that's explicitly jumping
around.
Anthony
On Fri, Apr 6, 2012 at 9:31 AM, Rasmus Schultz <ras...@mindplay.dk> wrote:
> 2012/4/5 Anthony Ferrara <ircmax...@gmail.com>:
>> Why not just do:
>>
>> function foo(callable $callback) {
>> $a = 0;
>> $callback();
>> $a = 1;
>> $callback();
>> }
>>
>> function bar() {
>> foo(function() { echo 1; });
>> }
>>
>> It's functionally the same, but doesn't have the stack magic.
>>
>> Now, it won't be able to do everything that your concept does (bubble
>> up to an arbitrary point), but I see that as a good thing, since this
>> is explicit. And considering that you're intending to use it as a
>> control flow structure (which is not what exceptions are supposed to
>> be), I would say exceptions and their dynamic nature would be
>> literally a bad thing in this case...
>
> I don't see how exceptions are anything but a control flow structure?
>
> If all you wanted was an error-message, you'd be using trigger_error()
> - the only way exceptions differ, is that they allow execution to
> continue from a certain point, under certain circumstances; it allows
> you to control the flow.
>
>> It's functionally the same, but doesn't have the stack magic.
>
> your argument and example above is certainly valid, but from the same
> point of view, why not get rid of throw/try/catch statements too while
> we're at it?
>
> function foo(callabable $errorhandler)
> {
> if (some_condition()) {
> $errorhandler();
> }
> }
>
> function bar() {
> foo(function() { echo 'an error occurred!'; exit; });
> }
>
> This works just as well, and as you pointed out, it's probably easier
> to understand.
>
> Now, it won't be able to do everything that an exception does (bubble
> up to an arbitrary point), but you could view that as a good thing,
> since this is explicit. You could argue that exceptions and their
> dynamic nature is literally a bad thing in every case.
>
> To your technical point:
>
>> This could get really ugly as you'd be
>> forced to have multiple stacks hanging around if you used more than
>> one of these in your code.
>
> I don't see how?
>
> If you throw an interrupt, and nothing catches it, the program
> terminates, same as after an exception.
>
> if you throw an interrupt and something catches it, that interrupt
> (and it's retained stack) only lives for the duration of the
> catch-statement:
>
> try {
> ...
> } catch (Interrupt $i) {
> if (some_condition())
> resume; // (A)
> else if (other_condition())
> throw $i; // (B)
> // (C)
> }
>
> There are three ways you can exit this catch{} block:
>
> (A) we resume execution from the throw-statement, and the previous
> stack remains valid.
>
> (B) the previous stack is preserved for another catch-statement (or
> exit with an error-message)
>
> (C) if we exit the catch{}-block and don't resume, it is safe to
> unwind the stack at this point. (assuming we're talking about just
> interrupts, and not continuations that can be serialized and resumed
> at a later time.)
>
> I don't know why you think interrupts are so unnatural or difficult to
> understand - to me, it would be a natural extension of exceptions. And
> I've never understood why they are so frequently compared to GOTO. I
> think it's entirely a matter of how you perceive (and apply) the idea
> of exceptions - personally I see them not as a "better" replacement
> for triggering errors, I really can't see them as anything other than
> flow-control statements; there are few cases from which it is really,
> truly impossible to recover, but when I identify such a case, I still
> use trigger_error() - and granted, this is rare, but there are cases.
>
> And mind you, registering an error-handler was possible before
> exceptions were around, and we got by then - just because something
> works or is well-established, doesn't mean there is no room for
> improvement.
>
> I'm not going to pretend I know enough about programming languages to
> say for sure that this is a good idea - if this idea has been tried or
> researched and proven "bad" already, I'd love to learn about it. But
> if so, I doubt it was for any of the reasons I've heard so far...
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
