[Yum-devel] urlgrabber: timestamp check

Michael Stenner mstenner at linux.duke.edu
Thu Mar 10 17:14:09 UTC 2005


On Wed, Mar 09, 2005 at 08:49:08PM -0500, Ryan Tomayko wrote:
> 
> On Mar 9, 2005, at 5:36 PM, Michael Stenner wrote:
> >>Yea. Not sure why we didn't do this in the first place.
> >
> >OK, I'll tell you what.  I'll go through and start doing this
> >EVERYWHERE it makes sense.  I think that's what bothered me the
> >most... just having this be special.  I'm pretty sure there won't be
> >need for any compat breaks.
> 
> Oh oh oh. I see what you mean by kludgy now. I thought this _was_ the 
> only place that HTTPError would be raised but now I see what you mean. 
> There's obviously many other places where this could happen.
> 
> My bad. Let me take a closer look at this like I promised. I do think 
> it would be a good idea to provide that level of error information for 
> HTTP errors when we have it. Do you think the impact is too high?

We're communicating badly.  In fact, I hadn't thought of what you just
mentioned.  You point out that

  a) there are other places HTTPError might be raised.

Damned good point.  I hadn't thought of it.  However, I suspect they
won't come from too many places... mostly those are response codes
(404, etc) and will happen when the connection is started.

What I was referring to is

  b) I'd like to see all exceptions (for which it makes sense) include
     equivalent data inside the URLGrabError object.  For example,
     when an IOError is raised and so WE raise a URLGrabError, I'd
     like to see the original exception embedded inside it.

     Well, I mean that if we're going to do that for one exception
     type (HTTPError) we should probably do it for all.

					-Michael
-- 
  Michael D. Stenner                            mstenner at ece.arizona.edu
  ECE Department, the University of Arizona                 520-626-1619
  1230 E. Speedway Blvd., Tucson, AZ 85721-0104                 ECE 524G



More information about the Yum-devel mailing list