[RFC] Exception is VDSM

[Saggi Mizrahi]

Well, the if you find it difficult to correlate a return value (exceptions are just fancy return values) with where they came from you have a very big problem.

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: "Simon Grinberg" <simon at redhat.com>, "arch" <arch at ovirt.org>, "VDSM Project Development"
> <vdsm-devel at lists.fedorahosted.org>
> Sent: Thursday, August 16, 2012 5:24:54 PM
> Subject: Re: [RFC] Exception is VDSM
> 
> 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.
>