I also think that retrieveByPK should return null if the key is not in the database, but should throw an exception if there are more than one row returned.
Case: I add the functionality to Scarab to be able to manage a list of contacts associated with a given bug. Each contact is an object stored in the database. Users of a given privilege are allowed to add/edit/delete contacts for a given bug. On the bug page a user clicks on a contacts link which displays the list of contact along with edit/delete buttons for each one. However, multiple user's have access to this page. Jane display's her list of contact for bug 123 then gets some coffee. John in the meantime displays his list of contacts for bug 123 and decides to delete contact [EMAIL PROTECTED] Meanwhile, Jane comes back and decides to delete the same contact, or decides to edit the contact. the web page Jane clicks will simply have some url like /junk/deletecontact?contactid=123 and this is a page that was generated before John deleted the contact. This is not an exceptional case. It is expected to happen in the corse of application usage just as a user may type "abc" into a phone number field. When the above case does happen you want to display a friendly error to Jane such as "Sorry, but that contact no longer exists.". However, you want to handle the case in which contactid=123 returns more than one contact very differently since it indicates something has gone very wrong, and is Exceptional. An Exception can also be thrown because of an entire array of database or jdbc problems. A developer cannot make the distinction between these clearly Exceptional cases and the object not existing. However, with all this said. Doesn't the manager method getInstance return null if no object matches? Byron John McNally wrote: > I think it is more likely that calling retrieveByPK returning 0 results > is an error than doing so with a Map get method call. Where did the PK > that returned 0 results come from? There is a pending patch to make the > exception vs. null configurable with a propery. I'm not sure I want to > go this way though. Can anyone provide me with some use cases that > supports the use of null vs. throwing an exception. i.e. when is it not > an exceptional condition? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
