[Yum-devel] rethinking RepoError

Chris Lumens clumens at redhat.com
Tue Sep 26 18:28:10 UTC 2006


I've been looking at error handling again, and have decided that
RepoError isn't really all that useful.  My particular complaint is that
it's too easy for RepoError to disguise the real cause of the exception.
setup in yumRepo.py shows my problem perfectly.

setup calls _loadRepoXML.  If there is a problem downloading a file in
this function, a URLGrabError exception will be raised but this is
handled by raising a RepoError with a generic error message.  At this
point, the real reason why the file could not be downloaded is lost -
was the problem a bad URL, a network timeout, a too busy server?  We
have no idea.  setup just compounds the problem by catching that
RepoError and raising a new one, with an even more generic error
message.

So the result is that the caller is now clueless as to why the file
could not be downloaded, just that there was a failure.  Perhaps this
works for the included yum user interfaces, but I don't think it works
for users of the API.  In anaconda, for instance, I would like to be
able to log the real failure cause so I have some debugging aid.

The first fix that sprang to mind was that RepoError could behave like
the SML/NJ Io exception.  One of the members of an Io exception
structure is another exception, with the name "cause".  This gives you
the complete details to the real problem.  If RepoError had the
URLGrabError packaged up inside it, callers could still just catch the
RepoError and if they cared to, inspect the cause to log it or print a
descriptive error message or whatever.  Otherwise, the exception behaves
like it always has.

Of course there are other solutions.  _loadRepoXML could not handle the
URLGrabError and leave it up to the callers, but that breaks everyone.
This also doesn't handle the other cases where it may be handy to have
the root cause.  RepoError could also just have some sort of message
describing the cause, but I do not like the relative lack of flexibility
there.

Thoughts?

- Chris



More information about the Yum-devel mailing list