Hi Michael;
That also seems like a good option.
Regards;
On 8/04/15 6:31 am, Michael Gentry wrote:
I could see having a requireOne() method that throws an exception if there
isn't exactly one match...
On Tue, Apr 7, 2015 at 2:15 PM, Andrew Lindesay <a...@lindesay.co.nz> wrote:
Hello Savva;
Thank you for that update. I had some thoughts on the "selectOne"
interface.
selectOne(ObjectContext);
I often find myself needing to assert that a single object is present
after querying for it. A good example would be querying for an item of
reference data by some 'code'. In this example there are three
possibilities;
1) I get nothing --> runtime exception
2) I get one object --> return it
3) I get more than one object --> runtime exception
The "selectOne(..)" method will (as-built) take care of dealing with the
#3 runtime exception for me, but still leaves me to handle the runtime
exception for #1. I wonder if...
T selectOne(context)
...should throw a runtime exception if it finds no result instead of
returning null. An additional signature...
T selectOne(context, T fallbackValue)
Could take a fallback value that could be presented in the case that the
query yielded no results. This would provide the functionality
as-implemented now.
Although it is not an option because of the language level of the project,
returning an Optional<T> (Java 8 / guava) would also provide a good way to
provide this functionality.
Regards;
--
Andrew Lindesay
--
Andrew Lindesay
