Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: When to throw RecordNotFoundException in find()

 
Dave Knipp
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I had a question concerning when to throw the RecordNotFoundException within the find method in Data. Here's the signature of find:

The only thing i could guess is that you are supposed to thrown the RecordNotFoundException when the find returns no matching results. Is this correct? Any suggestions?? Maybe its just a stupid question, but it just confused me a little since all of the other methods are throwing RecordNotFoundException when the recNo passed to it doesnt exist in the database. Just wanted to see what others thought.
Dave
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Dave,
Could you post the Sun's comment writtent above the method signature in the interface ? It could help to guess what they expect.
Best,
Phil.
 
Dave Knipp
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Phil,
Here's sun's comment that was above find() in the supplied interface:

They don't directly refer to how or when the RecordNotFoundException should be thrown so thats why i was questioning it. Does this help at all???
Thanks for taking a look at it,
Dave
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Dave,
OK, it seems that your version of find() is a bit silly. Mine (named findByCriteria()) has the same comments but doesn't throw RecordNotFoundException.
I see two ways of doing :
  • Don't declare the RecordNotFoundException in Data.find() and just return an empty array if no record matches.
  • Declare RecordNotFoundException in Data.find() and throw it just before returning (I mean instead of ) if no record matches.


  • Justifications of solution 1 :
  • The fact that the returned array is empty is enough to signal the caller that no record matches.
  • From the caller's perspective, dealing with the exception is harder than checking the returned array length.
  • It's not mandatory for a class implementing an interface to throw all exceptions declared in the interface. You cannot throw new or broader exceptions but well less exceptions or narrower ones.


  • Justifications of solution 2 :
  • The RecordNotFoundException in the find() throws clause in the interface suggests that it's the way Sun expects you to implement the method in Data.
  • I don't see any other argument.


  • I do prefer solution 1 but you'll have to make the choice by yourself ...
    Best,
    Phil.
    [ October 23, 2003: Message edited by: Philippe Maquet ]
     
    Dave Knipp
    Ranch Hand
    Posts: 146
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Phil,
    You bring up a valid point with solution #1. It is less hassle for the calling class (the client) to just check the size of the array to see if no records were found that match their criteria. But it is also something to think about since sun declared it to throw RecordNotFoundException. I think i lean toward the, not throwing it and then justifying it in choices.txt
    Thanks for your help,
    Dave
     
    Vlad Rabkin
    Ranch Hand
    Posts: 555
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,

    I agree with Phil
    Best,
    Vlad
     
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander
    Pie
    Posts: 12014
    220
    C++ Firefox Browser IntelliJ IDE Java Mac Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Phil,
    Originally posted by Philippe Maquet:
    Justifications of solution 2 :
  • The RecordNotFoundException in the find() throws clause in the interface suggests that it's the way Sun expects you to implement the method in Data.
  • I don't see any other argument.


  • For the client software required for this project, you are (probably) correct - handling reception of an empty array might be easier than handling an exception. But that depends on how the client is written, and what it considers "proper" response to either event.
    If the proper response is just to display an empty table, then certainly it will be easier. No handling required.
    But if you wanted to display a dialog box informing the user that the search failed, then catching an exception is the preferred way of doing things. Checking return values is very C/C++.
    And for other software that might use the same database, displaying an empty table might not be the correct way to do things - say you are printing reports on an expensive / highly used printer: do you really want to print an empty report? In which case I go back to my earlier statement that catching an exception is a more "Java" way of doing things.
    Originally posted by Philippe Maquet:
    I do prefer solution 1 but you'll have to make the choice by yourself ...

    Given that Sun have specified the exception in the method signature, I think it is obvious what they want
    Regards, Andrew
     
    Mark Spritzler
    ranger
    Sheriff
    Posts: 17278
    6
    IntelliJ IDE Mac Spring
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    So then why wouldn't be allowed for the find method to throw a RecordNotFound exception. I mean if I go trying to find something, and I don't find it, then it is "NotFound" and in the case of the find method what are you looking for but a record, so a RecordNotFOund could happen, and therefore you will want to through an excpetion of that type.
    And the biggest reason for throwing the exception, is because that is the signature that Sun gave you for that class, they don't rpovide you with much, but if it has this signature, then this is the signature they are looking for in your submission.
    Mark
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic