Returning null is the right solution now just because of precedent. Changing it would mean potentially breaking a lot of people's code without any added benefit.
I tend to think that returning null is more correct though. An object not being found is not an "exceptional event" that warrants the exception. The APIException not being thrown is a different issue. That is just to keep things consistent across all methods in the API. Ben On Sun, Jan 22, 2012 at 1:28 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < [email protected]> wrote: > Most OpenMRS objects, especially since the advent of REST, have > get<T>byUuid methods with signatures declaring that they throw an API > exception, but get the object by using a parameter query with > .uniqueResult() and without a try-catch block. .uniqueResult returns null > if there is no match and throws a Hibernate exception if there are multiple > results. We rely on a unique DB constraint to keep the results singular, > so perhaps a try-catch loop to change from a Hibernate to an API exception > is unnecessary, but in that case there’s no circumstance where the API > Exception would be thrown. Could someone confirm that returning null > rather than throwing the exception is the desired behavior?**** > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
