I agree with this. At the least, it should throw different exceptions. But returning null is in agreement with what other get-type functions do, like doing get on a HashMap
James At 05:41 PM 6/24/2002, you wrote: >What I don't like about this retrieveByPK() is that throws an exception >whenever returns a number of records different from 1. I think it should >throw the exception whenever the number of records is greater than 1 and >return null whenever there are no records. The reasoning behind this is that >when it returns more than 1 there is a problem with the model and it should >be considered and error. And when the number of records is 0 it only means >the record wasn't found but it can be very normal. The way it is now, there >is no way of distinguishing these cases when you call the method. > >-- > Humbertoi > >-----Original Message----- >From: John McNally [mailto:[EMAIL PROTECTED]] >Sent: Monday, June 24, 2002 2:03 PM >To: Turbine Torque Developers List >Subject: Re: Does this idea of merit? > > >There is a retrieveByPK method(s). > >john mcnally > >On Mon, 2002-06-24 at 11:54, James Turner wrote: > > I'm thinking about adding code to automatically generate a > > "getByPrimaryKey" method to the BasexxxPeer classes. Since this is the > > most commonly written method used in xxxPeer extensions, it would be a big > > > timesaver if a default "probably the right thing" version existed in the > > base, and it should be fairly straightforward to generate as the primary > > keys are called out in the XML. > > > > James > > > > > > -- > > To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > > > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > >-- >To unsubscribe, >e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
