Re: [vdsm] [RFC] Exception is VDSM
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" > To: "Saggi Mizrahi" > Cc: "Simon Grinberg" , "arch" , "VDSM > Project Development" > > 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" > > > To: "Saggi Mizrahi" > > > Cc: "arch" , "VDSM Project Development" > > > > > > Sent: Thursday, August 16, 2012 12:12:04 PM > > > Subject: Re: [RFC] Exception is VDSM > > > > > > > > > > > > - Original Message - > > > > From: "Saggi Mizrahi" > > > > To: "arch" , "VDSM Project Development" > > > > > > > > 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. > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] Exception is VDSM
On Thu, Aug 16, 2012 at 02:10:28PM -0400, Saggi Mizrahi wrote: > > > - Original Message - > > From: "Simon Grinberg" > > To: "Saggi Mizrahi" > > Cc: "arch" , "VDSM Project Development" > > > > Sent: Thursday, August 16, 2012 12:12:04 PM > > Subject: Re: [RFC] Exception is VDSM > > > > > > > > - Original Message - > > > From: "Saggi Mizrahi" > > > To: "arch" , "VDSM Project Development" > > > > > > 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. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] Exception is VDSM
- Original Message - > From: "Simon Grinberg" > To: "Saggi Mizrahi" > Cc: "arch" , "VDSM Project Development" > > Sent: Thursday, August 16, 2012 12:12:04 PM > Subject: Re: [RFC] Exception is VDSM > > > > - Original Message - > > From: "Saggi Mizrahi" > > To: "arch" , "VDSM Project Development" > > > > 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 > > a...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/arch > > > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] [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. 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. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
