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" <[email protected]> > To: "Saggi Mizrahi" <[email protected]> > Cc: "Simon Grinberg" <[email protected]>, "arch" <[email protected]>, "VDSM > Project Development" > <[email protected]> > 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" <[email protected]> > > > To: "Saggi Mizrahi" <[email protected]> > > > Cc: "arch" <[email protected]>, "VDSM Project Development" > > > <[email protected]> > > > Sent: Thursday, August 16, 2012 12:12:04 PM > > > Subject: Re: [RFC] Exception is VDSM > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Saggi Mizrahi" <[email protected]> > > > > To: "arch" <[email protected]>, "VDSM Project Development" > > > > <[email protected]> > > > > 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. > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
