Hi, All I can say is that I don't like exceptions, if we were using java 8 I would say go for Optional, that way the method with the defaults could be dropped and the user could decide what to do with the optional result. On the other had one does not expect the optional to contain null values We could also brew our own Optional...
http://java.dzone.com/articles/no-more-excuses-use-null An other option would be creating another override having 2 default values, one for no result and one for null. The more explicit the better. Cheers, F On Thu, Aug 29, 2013 at 10:06 AM, Rainer Döbele <[email protected]> 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 > > >
