Re: [Qemu-devel] [RFC] Fixing the error failure

[Luiz Capitulino <lcapitulino@redhat.com>]

On Wed, 20 Jun 2012 14:47:14 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> > I'm not sure this is better because it suggests that all classes we have today
> > are still valid.
> 
> Yes, they are still valid.  We cannot and should not change any of the error 
> behavior we have today.

We can keep them and do the new way only for new commands.

> > My main goal is to simplify,
> 
> My main goal is to get rid of all the printf() droppings we have scattered 
> through the code base.  There is absolutely not benefit in touching the current 
> users of Error.  They work fine.  We need to focus our attention on cleaning up 
> the crap that we have left.

We're talking about two different problems.

First, I agree about the issue with printf() and also agree about GenericError
being a solution to fix that. Although it's not clear to me how 'domain' should
be used and maybe we could extend UndefinedError to contain a user string and
use that instead.

The second problem is the 'rich error reporting has failed' one. This proposal
tries to address that. Declaring the current errors as deprecated doesn't
require us changing current users.

> > Also, maybe it's just how I'm interpreting it, but GenericError reminds of
> > UndefinedError in the sense that we'd prefer commands to use more specific
> > errors instead.
> 
> Using strings mean that errors are basically useless from a programmatic 
> perspective.  So yeah, it's just like using UndefinedError.  Except we may have 
> a few additional kinds of "UndefinedErrors" by having domains.
> 
> > I'm fine with keeping the current code, but I think this proposal overly
> > simplifies something that we're already overdoing.
> 
> We have something that works--why should we change it in any way?  There's no 
> maintenance burden here.

Because it got too complicated. We have 70+ error classes and a lot to come
with keep the current way.  It's already very difficult to choose the correct
class for an error and I don't doubt clients have a similar trouble in their end.
Besides, several errors are missing information to be really useful, like the
errno discussion.

I agree the burden is very little to maintain the current errors and I'm fine
with it, but I think we should move away from having hundreds of not so useful
classes.