On Mon, Dec 17, 2012 at 11:03 PM, Stas Malyshev <smalys...@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
