Re: [Twisted-Python] A kinder and more consistent defer.inlineCallbacks
glyph> I hope you mean "defer.fail()". Yes, sorry. glyph> As with the other case we mistakenly diagnosed here, it doesn't glyph> actually raise. It returns a failed Deferred. Consider: Yes, that was my original case, passing a non-generator and getting an attribute error when _inlineCallbacks calls send. That one I knew goes back via the Deferred. glyph> The only thing that (potentially) needs to be done here is to glyph> produce a more useful error message. glyph> The other case, where inlineCallbacks decorates a function that glyph> itself raises an exception rather than returns an object, is the glyph> only way you won't get a Deferred. That's what I was addressing in the code above. If you call the function in unwindGenerator and you get an exception, you 1) know it's not a generator (that's what I didn't understand earlier - calling a function with a yield in it can never give you an exception, Python builds you a generator and gives you that) and 2) can immediately give the exception back via defer.fail (your correction above). That's a simple change and makes sure you always get a Deferred back. Terry
On Sun, 23 Nov 2008 04:58:54 +0100, Terry Jones <terry@jon.es> wrote:
Not quite:
And unfortunately, there is essentially no way to differentiate this case from a case where the call to `f´ succeeded but some code executed as a result of that raised a `TypeError´. See also <http://twistedmatrix.com/trac/ticket/2501>. Jean-Paul
On Sun, 23 Nov 2008 04:58:54 +0100, Terry Jones <terry@jon.es> wrote:
Not quite:
And unfortunately, there is essentially no way to differentiate this case from a case where the call to `f´ succeeded but some code executed as a result of that raised a `TypeError´. See also <http://twistedmatrix.com/trac/ticket/2501>. Jean-Paul
participants (2)
-
Jean-Paul Calderone -
Terry Jones