16

Can somebody tell me the intrinsic reasons why in the JPA 1.0 EntityManager when retrieving an Object via find, you have to deal with null if not found, but when using the Query interface via createQuery getResultList throws a NoResultException when not found.

Maybe i am missing something but I feel its very inconsistent for a Language, and actually I had to do a lot of redesing because of changing from a simple finder to a more fine grained query using the query interface.

Thanks guys.

  • I think you have that wrong. queryForObject() throws an exception. queryForList() returns an empty list. – cletus Oct 16 '09 at 18:16
  • You missunderstand something. I am talking about javax.persistence.EntityManager and javax.persistence.Query. Check those interfaces you will understand. –  Oct 16 '09 at 18:52
  • @Jeff Are you sure that getResultList throws a NoResultException? – Grim Feb 08 '21 at 07:45

4 Answers4

27

Queries can be used to retrieve almost anything including the value of a single column in a single row.

If getSingleResult() would return null, you could not tell whether the query did not match any row or whether the query matched a row but the selected column contains null as its value.

ЯegDwight
  • 24,821
  • 10
  • 45
  • 52
Thorsten
  • 271
  • 3
  • 2
9

When you do a find, jpa will use the primary key to locate the entity object, often using second level cache and it is typically much faster than createQuery and getSingleResult.

You either get null or the Object back from find. When you do a createQuery and instance of Query object is created. If you do a getResultList it will not throw a NoResultException, only if you do a getSingleResult will it throw that exception. If you do a getResultList and none is found, then null will be returned.

Shervin Asgari
  • 23,901
  • 30
  • 103
  • 143
  • 4
    Thats correct yes. It is still not very clear to me why the JPA spec folks decided in one case throw a noresultexception and in the other just return null, if its logically very similar operation. That it is an unchecked exception doesn't make it easier ... or turned around: What speaked against returning null from getSingleResult vs. throwing an Exception? In my point of view that would be more consistent: Either throw a NoREsultExcpetion in getSingleResult and find or returning null. but not mix it. –  Oct 19 '09 at 22:13
  • 1
    getResultList() at least w/Eclipselink (which is the JPA2 reference implementation) will return an empty List not a NULL. – NBW Jun 13 '12 at 20:34
  • 1
    Yes for JPA2, but the question at the time was not for JPA2, but JPA – Shervin Asgari Jun 15 '12 at 12:14
2

Also, NoResultException will mark the transaction rolledback in weblogic 10.3.2.

See this article: NoResultException marks transaction rollback

Mike
  • 121
  • 1
  • 2
-1

I think it eliminates this null check :

Object o = q.getSingleResult();
if (o != null)
  return (MyObj) o;
return o;

By introducing a RuntimeException (NoResultException) , programmers can safely cast q.getSingleResult() to MyObj , and leave the exception to the caller.

As to q.getResultList() , it will always return a list , null-check is not necessary.

But I still feel this non-intuitive.

smallufo
  • 11,516
  • 20
  • 73
  • 111
  • 2
    -1 There is no need to check for `null` before casting, so this would be exactly the same as `return (MyObj) q.getSingleResult()` – Didier L Aug 02 '12 at 07:08