[RFC] Exception is VDSM

[Saggi Mizrahi]

----- 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.

Exception handling is about handling exceptions. Throwing something that cannot be handled seems to me like a needless complication.

I'm also only talking about public exceptions here.
> 
>      
> > 
> > Also exception like:
> > ImageDoesNotExistInSD
> > StoragePoolMasterNotFound
> > StoragePoolUnknown
> > VMPathNotExists
> > 
> > Actually just mean ENOENT or EntityDoesNotExist in different
> > contexts. There is no real reason to distinguish between them
> > because they are also context driven.
> > 
> > Cutting down on the amount of exceptions to error archetypes
> > similar
> > to standard c errors will give us simpler API.
> > Also, having a specific set of exceptions per call means that every
> > new API means a new group of supported exceptions. This makes
> > forward compatibility very problematic.
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
>