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
