[RFC] Exception is VDSM

[Dan Kenigsberg]

On Thu, Aug 16, 2012 at 02:10:28PM -0400, Saggi Mizrahi wrote:
> 
> 
> ----- Original Message -----
> > From: "Simon Grinberg" <simon at redhat.com>
> > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > Cc: "arch" <arch at ovirt.org>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> > Sent: Thursday, August 16, 2012 12:12:04 PM
> > Subject: Re: [RFC] Exception is VDSM
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > To: "arch" <arch at ovirt.org>, "VDSM Project Development"
> > > <vdsm-devel at lists.fedorahosted.org>
> > > Sent: Thursday, August 16, 2012 6:39:26 PM
> > > Subject: [RFC] Exception is VDSM
> > > 
> > > Currently we have very specific exceptions.
> > > This causes proliferation of exception with no real gain.
> > > 
> > > There is really no benefit for each call to throw it's own error
> > > message:
> > > For instance,
> > > MiscFileReadException
> > > MiscFileWriteException
> > > MiscBlockReadException
> > > MiscBlockWriteException
> > > * There are about a 100 of these.
> > > 
> > > Could all just be "general exception". The user knows what command
> > > it
> > > ran there is no need have the exceptions specify that.
> > 
> > Who is this 'user'?
> Any person or program that users the API.
> > 
> > Does 'user' operation necessary invokes just one of the above in a
> > 1:1 correlation to what he tries to do? no complex operation that
> > may lead to ambiguity?
> The reason is whether this "ambiguity" is important. For instance when calling getVolumeSize you might find EntityNotFound ambiguous as you don't at which point the search failed. Pool, Domain, Image, or Volume.
> The point I'm making is that it isn't important like open(2) returning ENOENT and not telling you at what point it failed the search. 99.9% of the time doesn't matter. If any of them are wrong, you need to change the "path" anyway because they are all dependent and there is no way for you to handle these differently. Also, in my opinion, returning StoragePoolUnknown is a mistake because this is all just a path to an entity. So you are talking about something else.

I'm guessing that Simon has alluded to Engine's difficulties to
correlate an error code with the specific API call that initiated it.
Unlike the kernel, where half of the syscalls have EPERM, Engine is (at
least used to be) confused by two verbs having the same error code.

Dan.