Going once, going twice.... consider it done. Clinton
On Fri, Aug 28, 2009 at 2:27 AM, Thanh PHAM <d...@pham.me> wrote: > 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 >> >> >>
