resume after exception

13 years ago by Ivan Enderlin @ Hoa — view source

unread

Hi Rasmus,

I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...

What if you could resume execution after an exception was thrown?

Fictive example:

function test()
{
echo "Begin Test!\n";

throw new Interrupt();

echo "Execution resumed!";
}

try
{
test();
}
catch (Interrupt $e)
{
echo "Execution interrupted.\n";
resume;
}

The output of this would be:

Begin Test!
Execution interrupted.
Execution resumed!
This feature seems to be interesting (from my point of view) but has
similarities with events (see below).

In other words, Interrupt is a new type of Exception, from which you can
recover, using the new resume keyword.
Why not "resume <i>"; like "break <i>;" or "continue <i>;", or maybe
"resume $exception;" to resume with another exception. It could be also
interesting to pass $this to the exception (we catch an exception, we
fix some data, we resume the execution).

The only thing that is disturbing me is your proposition looks like
synchronous events. Indeed, we fire an event, it lives somewhere in the
code and then execution is resumed.
Nevertheless, I think it could be interesting to have this feature for
exceptions.

Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

13 years ago by johannes@schlueters.de — view source

unread

I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...

What if you could resume execution after an exception was thrown?

So some random piece of code might cause other code to execute, which
was expected not to run (and therefore threw an exception).

I fear this brings hardly understandable code flows.

johannes

13 years ago by Alexey Shein — view source

unread

3 апреля 2012 г. 0:40 пользователь Johannes Schlüter
johannes@schlueters.de написал:

I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...

What if you could resume execution after an exception was thrown?

So some random piece of code might cause other code to execute, which
was expected not to run (and therefore threw an exception).

I fear this brings hardly understandable code flows.

Yeah, don't like it either. It seems like goto is coming back. Oh,
wait, goto is already come back in 5.3 :)

--
Regards,
Shein Alexey

13 years ago by johannes@schlueters.de — view source

unread

3 апреля 2012 г. 0:40 пользователь Johannes Schlüter
johannes@schlueters.de написал:

I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...

What if you could resume execution after an exception was thrown?

So some random piece of code might cause other code to execute, which
was expected not to run (and therefore threw an exception).

I fear this brings hardly understandable code flows.

Yeah, don't like it either. It seems like goto is coming back. Oh,
wait, goto is already come back in 5.3 :)

Actually our goto is limited to the scope, this "feature" is not, even
worse :-)

johannes

13 years ago by Sebastian Bergmann — view source

unread

I fear this brings hardly understandable code flows.

I second that emotion.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

13 years ago by Galen Wright-Watson — view source

unread

I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...

What if you could resume execution after an exception was thrown?

This is beginning to sound a lot like Common LISP's
conditionshttp://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html,
which isn't necessarily a bad thing. To get it to work, PHP would have to
preserve the stack when an exception is thrown (until the catch block is
exited), or store the exception/condition handler and execute it when the
exception is thrown/condition is signaled before unwinding the stack frame.

Taking this one step further, imagine it were also possible to serialize()
an Interrupt - and resume it at a later time. This would open up entirely
new possibilities for (AJAX) web-application frameworks, which would be
able to suspend execution, serialize the script state, return a response,
wait for further interaction from the user, and then resume execution.

This feels an unnatural use for an Interrupt, which models messages
between different levels of the execution stack. What you're describing is
better done with continuations
http://double.co.nz/pdf/continuations.pdf (PDF),
where you have an execution
treehttp://en.wikipedia.org/wiki/Saguaro_stack rather
than a stack. While continuations would certainly be cool, there are
definite performance and memory usage concerns involved with the various
implementations http://c2.com/cgi/wiki?ContinuationImplementation.

13 years ago by Samuel Giles — view source

unread

Hi Internals

function test()

{
echo "Begin Test!\n";

throw new Interrupt();

echo "Execution resumed!";
}

try
{
test();
}
catch (Interrupt $e)
{
echo "Execution interrupted.\n";
resume;
}

The output of this would be:

Begin Test!
Execution interrupted.
Execution resumed!

My major concern would be, how does this* really* add to PHP? Perhaps I'm
missing the point, but what would this allow that can't be done in some
form using well defined "patterns", for lack of a better word.

I'm not keen on the idea of throwing things such as Interrupts either, it
doesn't quite fit with their general use case.

Sam

13 years ago by Anthony Ferrara — view source

unread

Sam,

I'm not saying it's a good idea, but this would allow for pythonic
style generators. http://wiki.python.org/moin/Generators

Just pointing out one potential use-case...

Anthony

Hi Internals

function test()

{
echo "Begin Test!\n";

throw new Interrupt();

echo "Execution resumed!";
}

try
{
test();
}
catch (Interrupt $e)
{
echo "Execution interrupted.\n";
resume;
}

The output of this would be:

Begin Test!
Execution interrupted.
Execution resumed!

My major concern would be, how does this* really* add to PHP? Perhaps I'm
missing the point, but what would this allow that can't be done in some
form using well defined "patterns", for lack of a better word.

I'm not keen on the idea of throwing things such as Interrupts either, it
doesn't quite fit with their general use case.

Sam

13 years ago by Samuel Giles — view source

unread

Hi Anthony,

Ok, I see that now. I know you're not necessarily saying what's been
proposed is a good idea but I can see a benefit in pythonic style
generators as a separate piece of functionality, implementing a yield
function, has this ever been discussed before? My apologies if this is the
case I've not seen it since I've been following this list.

I know there is the SPL Iterator, but just as in the example you provided
implementations can be verbose and convoluted.

Cheers,
Sam

On Mon, Apr 2, 2012 at 10:34 PM, Anthony Ferrara ircmaxell@gmail.comwrote:

Sam,

I'm not saying it's a good idea, but this would allow for pythonic
style generators. http://wiki.python.org/moin/Generators

Just pointing out one potential use-case...

Anthony

On Mon, Apr 2, 2012 at 4:35 PM, Samuel Giles sam.e.giles@gmail.com
wrote:

My major concern would be, how does this* really* add to PHP? Perhaps
I'm
missing the point, but what would this allow that can't be done in some
form using well defined "patterns", for lack of a better word.

I'm not keen on the idea of throwing things such as Interrupts either, it
doesn't quite fit with their general use case.

Sam

13 years ago by Samuel Giles — view source

unread

Sorry, as an add on to my previous, a feature request was opened on the Bug
tracker in 2010 #51460 https://bugs.php.net/bug.php?id=51460 for a yield
syntax construct
Sam.

Hi Anthony,

Ok, I see that now. I know you're not necessarily saying what's been
proposed is a good idea but I can see a benefit in pythonic style
generators as a separate piece of functionality, implementing a yield
function, has this ever been discussed before? My apologies if this is the
case I've not seen it since I've been following this list.

I know there is the SPL Iterator, but just as in the example you provided
implementations can be verbose and convoluted.

Cheers,
Sam

On Mon, Apr 2, 2012 at 10:34 PM, Anthony Ferrara ircmaxell@gmail.comwrote:

Sam,

I'm not saying it's a good idea, but this would allow for pythonic
style generators. http://wiki.python.org/moin/Generators

Just pointing out one potential use-case...

Anthony

On Mon, Apr 2, 2012 at 4:35 PM, Samuel Giles sam.e.giles@gmail.com
wrote:

My major concern would be, how does this* really* add to PHP? Perhaps
I'm
missing the point, but what would this allow that can't be done in some
form using well defined "patterns", for lack of a better word.

I'm not keen on the idea of throwing things such as Interrupts either,
it
doesn't quite fit with their general use case.

Sam

13 years ago by Anthony Ferrara — view source

unread

Sam,

Just to be clear, I wasn't opposing pythonic generators. I was
opposing using this feature for that purpose. If we wanted
generators, I would suggest implementing them fully (as in adding a
yield statement).

However, that's not going to be as easy as it sounds, since what would
happen with a function like this:

function foo(array &$array) {
foreach ($array as $value) {
yield $value;
}
}

$array = array(1);
foreach (foo($array) as $value) {
$array[] = $value + 1;
}

Not saying it's not doable, just that it's not trivial to implement...

Anthony

Hi Anthony,

Ok, I see that now. I know you're not necessarily saying what's been
proposed is a good idea but I can see a benefit in pythonic style generators
as a separate piece of functionality, implementing a yield function, has
this ever been discussed before? My apologies if this is the case I've not
seen it since I've been following this list.

I know there is the SPL Iterator, but just as in the example you provided
implementations can be verbose and convoluted.

Cheers,
Sam

On Mon, Apr 2, 2012 at 10:34 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:

Sam,

I'm not saying it's a good idea, but this would allow for pythonic
style generators. http://wiki.python.org/moin/Generators

Just pointing out one potential use-case...

Anthony

On Mon, Apr 2, 2012 at 4:35 PM, Samuel Giles sam.e.giles@gmail.com
wrote:

My major concern would be, how does this* really* add to PHP? Perhaps
I'm
missing the point, but what would this allow that can't be done in some
form using well defined "patterns", for lack of a better word.

I'm not keen on the idea of throwing things such as Interrupts either,
it
doesn't quite fit with their general use case.

Sam

13 years ago by Charlie Somerville — view source

unread

Magnus Holm has an excellent proof of concept for this in Ruby, which
supports continuations:

http://timelessrepo.com/never-gonna-let-you-go

I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...

What if you could resume execution after an exception was thrown?

Fictive example:

function test()
{
echo "Begin Test!\n";

throw new Interrupt();

echo "Execution resumed!";
}

try
{
test();
}
catch (Interrupt $e)
{
echo "Execution interrupted.\n";
resume;
}

The output of this would be:

Begin Test!
Execution interrupted.
Execution resumed!

In other words, Interrupt is a new type of Exception, from which you can
recover, using the new resume keyword.

Taking this one step further, imagine it were also possible to serialize()
an Interrupt - and resume it at a later time. This would open up entirely
new possibilities for (AJAX) web-application frameworks, which would be
able to suspend execution, serialize the script state, return a response,
wait for further interaction from the user, and then resume execution.

I'm sure there are lots of problems with this idea, and perhaps it's not a
good fit for PHP at all, but I figured it couldn't harm to put the idea out
there anyway :-)

Any thoughts?

13 years ago by reeze — view source

unread

If just for exception recovery how about implement ruby's retry ?

http://www.tutorialspoint.com/ruby/ruby_loops.htm Ruby retry statement section.

在 2012年4月2日星期一，下午8:44，Rasmus Schultz 写道：

I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...

What if you could resume execution after an exception was thrown?

Fictive example:

function test()
{
echo "Begin Test!\n";

throw new Interrupt();

echo "Execution resumed!";
}

try
{
test();
}
catch (Interrupt $e)
{
echo "Execution interrupted.\n";
resume;
}

The output of this would be:

Begin Test!
Execution interrupted.
Execution resumed!

In other words, Interrupt is a new type of Exception, from which you can
recover, using the new resume keyword.

Taking this one step further, imagine it were also possible to serialize()
an Interrupt - and resume it at a later time. This would open up entirely
new possibilities for (AJAX) web-application frameworks, which would be
able to suspend execution, serialize the script state, return a response,
wait for further interaction from the user, and then resume execution.

I'm sure there are lots of problems with this idea, and perhaps it's not a
good fit for PHP at all, but I figured it couldn't harm to put the idea out
there anyway :-)

Any thoughts?

13 years ago by Kiall Mac Innes — view source

unread

Retry is a feature I would very much like to see...

While it's not stritcly necessary to implement in core, it makes the code
much cleaner..

Thanks,
Kiall

Sent from my phone.

If just for exception recovery how about implement ruby's retry ?

http://www.tutorialspoint.com/ruby/ruby_loops.htm Ruby retry statement
section.

在 2012年4月2日星期一，下午8:44，Rasmus Schultz 写道：

I was just reading about the new async/await keywords in C# 5.0, and
while
this has no particular relevance to PHP as such, it got me thinking about
this idea...

What if you could resume execution after an exception was thrown?

Fictive example:

function test()
{
echo "Begin Test!\n";

throw new Interrupt();

echo "Execution resumed!";
}

try
{
test();
}
catch (Interrupt $e)
{
echo "Execution interrupted.\n";
resume;
}

The output of this would be:

Begin Test!
Execution interrupted.
Execution resumed!

In other words, Interrupt is a new type of Exception, from which you can
recover, using the new resume keyword.

Taking this one step further, imagine it were also possible to
serialize()
an Interrupt - and resume it at a later time. This would open up entirely
new possibilities for (AJAX) web-application frameworks, which would be
able to suspend execution, serialize the script state, return a response,
wait for further interaction from the user, and then resume execution.

I'm sure there are lots of problems with this idea, and perhaps it's not
a
good fit for PHP at all, but I figured it couldn't harm to put the idea
out
there anyway :-)

Any thoughts?

13 years ago by Rasmus Schultz — view source

unread

interesting, but this doesn't have anything in particular to do with
what I was talking about.

to the best of my understanding, an exception transfers control back
to the nearest calling code that has declared it is ready/willing/able
to resume control in the event that, somewhere up the call-stack, a
condition occurs that causes an exception.

it's a wonderful mechanism with more uses than simply reporting errors

the aspect of transferring control is what I find really interesting
about exceptions.

with regards to transferring control, why does it strike you as so
unnatural to also provide a mechanism for returning control?

to me, it seems like a perfectly natural extension of that mechanism -
and of course, not as something that just happens, but as a feature
you can opt into.

since breaking program flow is already supported by exceptions, and
since that is the first half of the mechanism I have in mind, I
thought it would be natural to have an extended type of exception (I
called it an "interrupt") where it is also possible to resume program
flow after the throw-statement.

the way I defined it, as with exceptions, this requires a formal
declaration to do so, both on the part of the throwing code, and on
the part of the code that catches and assumes control after the throw.
exceptions aren't guaranteed to be handled, and similarly, there's no
guarantee that control will be returned to the throwing code after an
interrupt. for all intents and purposes, it's still an exception, and
can be handled as an exception too - the difference is, by throwing an
interrupt, you've agreed to possibly resuming execution after the
interrupt is handled, if the interrupt is caught and the catching code
decides to return control.

it's not a one-way transfer of control like a goto, where you have to
test for conditions and decide where to transfer control on a
case-by-case basis. in my mind, the term "spaghetti" doesn't describe
the program itself, but the more or less unpredictable execution path,
which can only be understood by trying to "execute" the program in
your mind. exceptions (and what I call an interrupt) does not allow
you to sporadically transfer control just anywhere, but rather follows
the well-understood mechanics of an exception, with a hierarchical
execution path - just with the added benefit of returning control from
the exception-handler after catching and handling it.

taking this one step further (with state-serialization and
continuation) was just an afterthought, something that occurred to me
while I was typing - that may be taking it too far, and really wasn't
something I've been thinking about deeply...

If just for exception recovery how about implement ruby's retry ?

http://www.tutorialspoint.com/ruby/ruby_loops.htm Ruby retry statement
section.

在 2012年4月2日星期一，下午8:44，Rasmus Schultz 写道：

I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...

What if you could resume execution after an exception was thrown?

Fictive example:

function test()
{
echo "Begin Test!\n";

throw new Interrupt();

echo "Execution resumed!";
}

try
{
test();
}
catch (Interrupt $e)
{
echo "Execution interrupted.\n";
resume;
}

The output of this would be:

Begin Test!
Execution interrupted.
Execution resumed!

In other words, Interrupt is a new type of Exception, from which you can
recover, using the new resume keyword.

Taking this one step further, imagine it were also possible to serialize()
an Interrupt - and resume it at a later time. This would open up entirely
new possibilities for (AJAX) web-application frameworks, which would be
able to suspend execution, serialize the script state, return a response,
wait for further interaction from the user, and then resume execution.

I'm sure there are lots of problems with this idea, and perhaps it's not a
good fit for PHP at all, but I figured it couldn't harm to put the idea
out
there anyway :-)

Any thoughts?

13 years ago by Anthony Ferrara — view source

unread

Rasmus,

What would that give you that a continuation passing paradigm
wouldn't? Why not tell the code what to call before you call it,
rather than bubbling up the stack (which then forces a fork of the
stack, as you need to partially unwind it, but keep track of what you
unwound for the resume). 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.
So, instead of:

function foo() {
$a = 0:
throw new Interrupt();
$a = 1;
throw new Interrupt();
}

function bar() {
try {
foo():
} catch (Interrupt $i) {
echo 1;
resume;
}
}

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...

Anthony

2012/4/5 Rasmus Schultz rasmus@mindplay.dk:

interesting, but this doesn't have anything in particular to do with
what I was talking about.

to the best of my understanding, an exception transfers control back
to the nearest calling code that has declared it is ready/willing/able
to resume control in the event that, somewhere up the call-stack, a
condition occurs that causes an exception.

it's a wonderful mechanism with more uses than simply reporting errors

the aspect of transferring control is what I find really interesting
about exceptions.

with regards to transferring control, why does it strike you as so
unnatural to also provide a mechanism for returning control?

to me, it seems like a perfectly natural extension of that mechanism -
and of course, not as something that just happens, but as a feature
you can opt into.

since breaking program flow is already supported by exceptions, and
since that is the first half of the mechanism I have in mind, I
thought it would be natural to have an extended type of exception (I
called it an "interrupt") where it is also possible to resume program
flow after the throw-statement.

the way I defined it, as with exceptions, this requires a formal
declaration to do so, both on the part of the throwing code, and on
the part of the code that catches and assumes control after the throw.
exceptions aren't guaranteed to be handled, and similarly, there's no
guarantee that control will be returned to the throwing code after an
interrupt. for all intents and purposes, it's still an exception, and
can be handled as an exception too - the difference is, by throwing an
interrupt, you've agreed to possibly resuming execution after the
interrupt is handled, if the interrupt is caught and the catching code
decides to return control.

it's not a one-way transfer of control like a goto, where you have to
test for conditions and decide where to transfer control on a
case-by-case basis. in my mind, the term "spaghetti" doesn't describe
the program itself, but the more or less unpredictable execution path,
which can only be understood by trying to "execute" the program in
your mind. exceptions (and what I call an interrupt) does not allow
you to sporadically transfer control just anywhere, but rather follows
the well-understood mechanics of an exception, with a hierarchical
execution path - just with the added benefit of returning control from
the exception-handler after catching and handling it.

taking this one step further (with state-serialization and
continuation) was just an afterthought, something that occurred to me
while I was typing - that may be taking it too far, and really wasn't
something I've been thinking about deeply...

If just for exception recovery how about implement ruby's retry ?

http://www.tutorialspoint.com/ruby/ruby_loops.htm Ruby retry statement
section.

在 2012年4月2日星期一，下午8:44，Rasmus Schultz 写道：

I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...

What if you could resume execution after an exception was thrown?

Fictive example:

function test()
{
echo "Begin Test!\n";

throw new Interrupt();

echo "Execution resumed!";
}

try
{
test();
}
catch (Interrupt $e)
{
echo "Execution interrupted.\n";
resume;
}

The output of this would be:

Begin Test!
Execution interrupted.
Execution resumed!

In other words, Interrupt is a new type of Exception, from which you can
recover, using the new resume keyword.

Taking this one step further, imagine it were also possible to serialize()
an Interrupt - and resume it at a later time. This would open up entirely
new possibilities for (AJAX) web-application frameworks, which would be
able to suspend execution, serialize the script state, return a response,
wait for further interaction from the user, and then resume execution.

I'm sure there are lots of problems with this idea, and perhaps it's not a
good fit for PHP at all, but I figured it couldn't harm to put the idea
out
there anyway :-)

Any thoughts?

13 years ago by Stas Malyshev — view source

unread

Hi!

it's a wonderful mechanism with more uses than simply reporting errors

the aspect of transferring control is what I find really interesting
about exceptions.

Exceptions should not be used for flow control. They are called
"exceptions" for a reason - to signify that something unusual
(exceptional) happened outside normal application functionality, which
now needs to be abandoned and the application should switch into "the
sky is falling, how I get out of it without losing too much?" mode. If
you're using exceptions for anything that is normal for your
application, you're doing it wrong.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Galen Wright-Watson — view source

unread

2012/4/5 Stas Malyshev smalyshev@sugarcrm.com

Hi!

it's a wonderful mechanism with more uses than simply reporting errors

the aspect of transferring control is what I find really interesting
about exceptions.

Exceptions should not be used for flow control. [...]

While exceptions themselves may not be suitable for a general-purpose
control structure, they do embody one. It's an early-return mechanism that
you also see in some of the other control structures mentioned in this
thread (Python's generators, Common LISP's conditions). Even the "return"
statement itself could be considered a simpler form of it, with the
difference that "return" can only go up a single invocation while "throw"
can exit an arbitrary number of them (also, "throw" is limited in the type
of value it can return).

The argument against any early-return mechanism is that it creates a
too-complex control flow. This is the same argument from the structured
programming wars about having multiple exit
pointshttp://c2.com/cgi/wiki?SingleFunctionExitPoint from
a function, in support of having a single return at the end of functions.
It certainly can produce messy, hard to understand code, but it can also be
quite powerful, simplifying certain problems. Perhaps there's some middle
ground that balances clarity, simplicity and power.

13 years ago by Stas Malyshev — view source

unread

Hi!

While exceptions themselves may not be suitable for a general-purpose
control structure, they do embody one. It's an early-return mechanism that
you also see in some of the other control structures mentioned in this
thread (Python's generators, Common LISP's conditions). Even the "return"

You can do the same generators do using iterators in PHP. You'll have to
store state a bit more explicitly, but otherwise it'd be pretty much the
same, as far as I can see.
However, in general, thinking about more complex flow control structures
in fine. Just there's no reason to get exceptions mixed into it.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Galen Wright-Watson — view source

unread

On Thu, Apr 5, 2012 at 4:47 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:

However, in general, thinking about more complex flow control structures
in fine. Just there's no reason to get exceptions mixed into it.

Agreed. While restarting and resuming after exceptions could be useful,
and a condition signaling control structure could also be useful, the two
should be distinguished at the language level (even if they were
implemented using the same mechanism under the hood).

So, what do people think of some sort of retry mechanism for exceptions?
What about a (separate) condition signaling control structure? What about
serializable continuations, allowing for resuming execution in a separate
request?

CPS offers an alternative to the first two. As much as the idea appeals to
me, retries seem less useful to me in PHP than in other languages unless
(as Rasmus initially suggested) execution were serializable, which I
suspect would be a heavy feature.

Serializable continuations would require the most work to implement using
PHP if it's never supported by the language itself. I suspect that
serializable continuations will be space-inefficient no matter where
they're implemented. Web continuations may not be common practice now, but
part of the reason for that may be lack of support. It could become more
popular if it were available. On the other hand, PHP's heritage as a
templating language means serializable continuations may be just as much a
problem as "die" or "exit" is, as they can result in invalid HTML.

13 years ago by Rasmus Schultz — view source

unread

2012/4/5 Anthony Ferrara ircmaxell@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...

13 years ago by Anthony Ferrara — view source

unread

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

2012/4/5 Anthony Ferrara ircmaxell@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...