Hi, I think, I would probably go in the `Optional` direction as Francis explained. I would create a class that encodes all the possible cases that can come out of a call to `querySingelInt` and other such methods.
The result object could have similiar features like the `Optional` or `Try` class from scala, maybe even more specific to this use case. my 2 cents... Kind regards Eike On [Thu, 29.08.2013 10:06], Rainer Döbele wrote: > Hi everyone, > > > > I have some problems with EMPIREDB-189 as I am not sure what to do. > > > > In DBDatabase we have serveral overloads for querySingleValue, > querySingleInt, querySingleLong etc. which all return a scalar value. > > Some of those overloads take a parameter for a default value like e.g. > > > > int querySingleInt(DBCommand cmd, int defaultValue, Connection conn); > > > > Now the problem is, that the query faces two possible cases that we must deal > with: > > 1. The result of the query is null (or anything but a number) 2. The query > has no result at all, i.e. no row was returned > > > > For case 1 the defaultValue is correctly returned. > > For case 2 we throw a QueryNoResultException as described in the JavaDoc. > > So basically everything works as designed. > > > > However as Harald Kirsch reported, it might be desirable to have the > defaultValue returned for both cases instead of an exception in case 2. > > On the other hand this has the following drawbacks: > > 1. Those methods without a defaultValue would still throw and exception for > case 2 and return null (or 0) for case 1, thus making the be behavior of the > different overloads inconsistent 2. There is no way to distinguish between > the two cases > > > > Basically we have IMO three options: > > 1. Leave everything as it is > > 2. Change only the behavior of the overloads with a defaultValue not to throw > an exception but to return the defaultValue instead 3. Change the behavior of > all querySingleValue methods not throw an exception and instead return the > defaultValue or null (or 0 or "") > > > > One argument for changing the behavior is, that in many cases these methods > are used for finding out whether a database record exists or not and an > exception is not desired. > > > > What's your opinion? > > > > Regards > > Rainer > > > -- email: [email protected] https://eknet.org pgp: 481161A0
