Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64328
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50CF969D.8090707@sugarcrm.com>
References: <CAF+90c8q17CBk49vDLcczJ_4Dp7YcYHGMgDQqa6j6bogBvJmsQ@mail.gmail.com>
	<50CF969D.8090707@sugarcrm.com>
Date: Mon, 17 Dec 2012 23:45:04 +0100
Message-ID: <CAF+90c8pBWc41vQzUJE4p9Xyd1edZGjrmm_XrO4AaqwaqLixGg@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d040716dddea98c04d114210c
Subject: Re: [PHP-DEV] Adding Generator::throw()
From: nikita.ppv@gmail.com (Nikita Popov)

--f46d040716dddea98c04d114210c
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 17, 2012 at 11:03 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > Basically the method allows you to do delegate error handling to the
> > coroutine, rather than doing it yourself (as you are not always able to
> do
> > it). It is particularly useful in more complicated settings, e.g. if you
> > are doing task scheduling through coroutines. For a small sample of how
>
> Could you expand on this point a bit more? It sounds like using
> exceptions for flow control, which is usually a very bad idea.
>
> > this looks like see http://taskjs.org/. What the ->throw() method would
> do
> > in these examples is that it allows to check for errors by try/catching
> the
> > yield statement (rather than going for some odd solution with error
> > callbacks).
>
> Could you point to some specific example?
>
The basic idea behind this kind of task management is that you can do
asynchronous operations just like you would synchronous ones, i.e. without
the need for callbacks or wait-loops. Whenever the functions wants to
perform some async action it doesn't directly do it, rather it yields the
operation that does it. The scheduler then waits until that operation is
finished (running other tasks in the meantime) and only resumes the
coroutine once it is finished. This way you can write async code without
the ugliness that is usually involved with async code.

Here is an example to get a rough idea of how the use looks like:

function server() {
    // ...
    $stuff = yield $socket->recv();
    // ...
    yield $socket->send($response);
    // ...
}

The throw() method comes in when you want to handle errors on those
asynchronous operations. Without it you would be forced to use error codes.
throw() allows you to do the error handling just like you would normally
do. E.g. consider that $socket->send() were a fallible operation. Then you
could catch errors like this:

function server() {
    // ...
    try {
        yield $socket->send($response);
    } catch (SocketException $e) {
        // do some error handling
    }
    // ...
}

In this case the outside code (where the exception comes from) can't know
what it should do in case of an error. Only the code in the coroutine knows
that. That's why you need some possibility to throw the error into the
context that knows how to deal with it.

I hope that this makes it a bit more clear.

Nikita

--f46d040716dddea98c04d114210c--