On 17.10.12 12:38, Greg Ewing wrote:
Guido van Rossum wrote:
On Tue, Oct 16, 2012 at 2:14 PM, Greg Ewing greg.ewing@canterbury.ac.nz wrote:
The important idea is that just because you spawn a task, it doesn't necessarily follow that you want to be regarded as the *parent* of that task and receive its exceptions.
Maybe. But the opposite doesn't follow either. It's a toss-up between the spawner and the waiter.
So maybe spawn() should have an option indicating that the spawning task is to receive exceptions occuring in the spawned task.
No idea if that helps here, but the same problem occurred for us as well. It is not always clear if an exception should be handled in a certain context, or if it should be passed on and get raised later in the context that is concerned.
For that, Stackless has introduced a _bomb_ object that encapsulates an exception, in order to let it pass through the normal call/yield/return interface. It is used to send an exception over a channel, which will explode (raise that exception) when the receiver picks it later up.
I could think of something similar as a way to collect very many results in a join construct that collects everything without the need to handle each exception in the very moment it was raised.
That would make it possible to collect results efficiently using 'yield from' and inspect the results later.
Probably nothing new, just mentioned an idea...