[Yum-devel] [PATCH] get retrycode *after* failure_callback has run

[James Antill]

On Thu, 2012-06-28 at 03:01 -0400, Zdenek Pavlas wrote:
> >  This is so the failure handler can change it, right?
> 
> Yep
> 
> >  And I assume the exceptions aren't in a singleton or something
> >  weird, so if the handler calls urlgrabber it won't overwrite previous data?
> 
> It's a subclass of IOError so there's some magic in it,
> but instances are independent and errno attribute is r/w.
> One possible surprise I know of is:
> 
> >>> e=URLGrabError(1, "Foo")
> >>> e.errno=2
> >>> e.errno==2
> True
> >>> e
> URLGrabError(1, 'Foo')
> 
> ..since str() uses original e.args tuple.

 Ugh. That is inherited from IOError. Which implies that core python
devs. think IOError should be r/o.

> > to know if it can/should change the exception data.
> 
> if e.errno==14 and e.code==503: e.errno=-1 # retry
> 
> I'd put something like that in the callback,
> that's probably specific/safe enough.
> 
> > ACK unless you can think of a better way :).
> 
> First idea was overriding the errcode with callback's
> return value, unless it's None.   Currently it's ignored
> and callbacks return None, but we can't be sure.
> r/w errno seems much better (atm).

 We could maybe test the return value and if it's a URLGrabError() then
use that ... maybe slightly nicer. Just hacking the exception is
probably going to be safe though.
 Upto you.