I agree with Zoran and would prefer to return null on 0 too. 2009/8/28 Zoran Avtarovski <zo...@sparecreative.com>
> Thanks Clinton, > > I agree with you, at least I think I do. > > I think only throwing an exception on only more than one object is a great > idea. > > In our standard approach we often see requests for objects that have been > deleted. All we do is test for null and then respond appropriately. What > concerns me is that the current approach will have us try, catch, test to > see what caused the error and then respond appropriately. > > Where I’d prefer to return null on 0, object for 1 and then throw a > TooManyObjects error – the name of the error is irrelevant :) This way a > simple null test is all that is needed in non exceptional circumstances. > > Z. > > > This is an interesting case... It's based on two best practices: > > 1) You should not use try/catch for flow control. So if you're catching > the exception to deal with a non-exceptional (i.e. normal) case, then you're > probably abusing the exception. > > 2) It's not a good idea to return null when one was requested. > > The idea here is that if you don't know how many results will be returned > (e.g. 0, 1 or N), then you should use selectList(). However, if you do know > that the instance absolutely exists, then you should use selectOne(). > > If this practice seems like a lot of arm waving and not terribly practical, > then that's what I'd like to hear from people. Otherwise, does anyone agree > with the design? I can easily eliminate the exception on 0 or 1, and > instead only throw an exception on many (which makes sense). > > I agree that the exception should be better... but I don't suggest using it > for flow control. > > Thoughts? > > Clinton > > >
