Need for ObjectNotFoundException

Discussions

EJB design: Need for ObjectNotFoundException

  1. Need for ObjectNotFoundException (3 messages)

    Why do we require an ObjectNotFoundException? Why cannot an EJB simply return a null value. Why do we need the extra overhead of catching and handling ObjectNotFoundException.

    Thanks,

    Threaded Messages (3)

  2. Need for ObjectNotFoundException[ Go to top ]

    Hi Vinay,

    Exceptions the usual way of informing the caller of a method that something unexpected has happened. So the question is, does 'not able to find the entity in a single-object finder method' fall into that category. I suppose the team that made the spec thought single-finder methods would most often be used in situations where the enity is expected to exist so they forced us to handle such cases the Java way.

    Makes sense?
  3. Need for ObjectNotFoundException[ Go to top ]

    Hi Paul,

    ObjectNotFoundException essentially informs the end user that there is no data for the data retrieval condition specified. This is a normal condition not an unexpected one and definitely not an exceptional condition.

    If one looks at the programming practices, exceptions are used to inform caller of failures. Exceptions are used to inform the user of program termination due to abnormal process operation(in case of database interactions, failure in CRUD operations.), which does not apply in case of no data found condition.

    Considering the above, I am not able to understand the we need to handle an Exception instead of a null return.

    Besides, handling an exception adds extra overheads vis-a-vis a null check.
  4. its real simple[ Go to top ]

    There are two schools of thought:

    try {
      Object o = find();
      o.xxx();
    } catch (...) {

    }

    or

    Object o = find();
    if (o != null) {
      o.xxx();
    }

    It merely a question of how you wish to code. I personally prefer the first method if there is a pretty good chance that an object is coming back which is expected if one were to have a primary key. Otherwise you are always checking for null when the truth is that if you got a primary key from a query or through some other reliable means then it is an extremely good chance that it is still there and all that null checking is a total waste of time (programmer time). But it can easily be done the other way. Someone made a choice.

    Bruce