Shouldn't exceptions be reliably reported? Silencing exceptions doesn't seem like a sound idea to me because it may lead to subtle bugs and is a bit misleading IMHO On 4 Apr 2013 16:57, "Kristján Valur Jónsson" <[email protected]> wrote:
> I’ve been thinking some more about this. **** > > It should be ok to kill a tasklet that hasn’t run yet. And killing a dead > one should be a no-op.**** > > Rather than making “kill” have special semantics, how about just applying > that rule? An exception sent to a tasklet that hasn´t run yet just > disappears and the tasklet dies.**** > > An exception sent to a dead tasklet just disappears.**** > > I think these are sensible semantics. In my opinion, it was a mistake to > design stackless such that uncought tasklet exceptions were sent to the > main tasklet.**** > > K**** > > ** ** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Kristján Valur Jónsson > *Sent:* 4. apríl 2013 09:45 > *To:* The Stackless Python Mailing List ([email protected]) > *Subject:* [Stackless] added tasklet.throw**** > > ** ** > > Yesterday I checked in a new feature to stackless.**** > > Tasklets now have a new function, „throw“, which enhances the already > present tasklet.raise_exception().**** > > ** ** > > The docstrings:**** > > "tasklet.throw(exc, val, tb, immediate=True) -- raise an exception for the > tasklet.\n\**** > > 'exc', 'val' and 'tb' have the same semantics as Python's > 'raise' statement.\n\**** > > If 'immediate' is True, the tasklet is immediately activated, > otherwise, it is\n\**** > > merely made runnable");**** > > ** ** > > ** ** > > This brings two new features:**** > > **a) **unifies the argument semantics. It now takes the same three > arguments as a python „raise“ expression, just like channel.send_throw() > already does.**** > > **b) **It allows the target to be scheduled, rather than invoked > immediately. This is useful in frameworks, for example to send a timeout > error to a tasklet without interrupting regular scheduling.**** > > **c) **if the exception cannot be sent because the target is > dead/not yet running, then a RuntimeError is raised. **** > > ** ** > > ** ** > > item c) is the reason we can‘t let the existing kill and raise_exception > methods use this. They have the confusing property that if the target is > dead or not running yet, the error will be raised on the main tasklet > instead. I actually think that this is a pretty bad idea. I wonder if > anyone is depending on this? If not, I can make kill and raise_exception a > special case of the new one.**** > > ** ** > > (channel.send_throw() is also a fairly recent addition. An improvement on > channel.send_exception() it allows the user to send an existing excetption > instance, and a traceback, over the channel. It is particularly the > sending of tracebacks which is useful when handling errors.)**** > > K**** > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless >
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
