[Python-ideas] [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

[Guido van Rossum]

On Wed, Jan 9, 2013 at 4:13 AM, Richard Oudkerk <shibturn at gmail.com> wrote:
> On 09/01/2013 10:54am, Nick Coghlan wrote:
>>
>> You need to combine it with the other LBYL checks (f.done() and
>> f.cancelled()) to be sure it won't throw an exception.
>>
>>      if f.done() and not f.cancelled():
>>          # Since we now know neither TimeoutError nor CancelledError can
>> happen,
>>          # we can check for exceptions either by calling f.exception() or
>>          # by calling f.result() inside a try/except block
>>          # The latter will usually be the better option
>>
>> Just calling f.result() is by far the most common, but the other can
>> be convenient in some cases (e.g. if you're writing a scheduler that
>> needs to check if it should be calling send() or throw() on a
>> generator).
>
>
> Which goes to show that it cannot be used with LBYL.
>
> For exception() to be usable with LBYL one would need to be able to check
> that exception() returns a value without having to catch any exceptions --
> either from exception() or from result().
>
> But you can only check that exception() doesn't raise an error by calling
> result() to ensure that it does raise an error.  But then you might as well
> catch the exception from result().
>
> And the idea of calling exception() first and then result() if it fails is
> just crazy.
>
> As things stand, exception() is pointless.

Not true -- if the future has a callback associated with it, the
callback (or callbacks) is called when it becomes "done", and if the
callback wants to check for an exception it can use exception(). The
callback is guaranteed that the future is done so it doesn't have to
worry about the exception that is raised if the future isn't done. (Of
course a callback can also just call result() and catch the exception,
or let it bubble out -- in that case it will be logged by the event
loop and then dropped.)

-- 
--Guido van Rossum (python.org/~guido)