• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

B&S Appropriate Use of Exception

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All

In my interface it specifies that the find method throws a RecordNotFoundException:

public int [] find(String [] criteria) throws RecordNotFoundException;

When I am looping through all of the records in the database to find matching records I have made the decision to 'swallow and log' any RecordNotFoundException's and continue searching the database. Once I have been through the entire if no matching records have been found THEN I throw a RecordNotFoundException to indicate that no matching records were found.

My instructions state: "Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file".

Given the statement from the instructions about RecordNotFoundException's, do you think that my use of the RecordNotFoundException when no matching records are found is ok?

Thanks

Simon
 
Simon O'Brien
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another thought ....

Do you think it would be better for the find method to just return null if no matching records were found (instead of throwing the RecordNotFoundException)?

The only negative I can see with this is that the interface declares that the find() method throws a RecordNotFoundException but my find() code will never actually throw the RecordNotFoundException.

Any thoughts?

Thanks again!

Simon
 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Simon, based on the definition of the RecordNotFoundException, I feel that return a null when there are no matching records seems more appropriate.

Or another solution is to create a custom RuntimeException, for example NoRecordsFoundException. However I feel that its common for search functions to return no results and hence not really an exception case.

Do remember to document your decision!

Regards,
Zengwei
 
Ranch Hand
Posts: 169
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi all;

i think when there are no record to return , the best is to return an array of int value with zero size rather than null , becuase the caller for this method expect any array and he will loop on this array , if the array have no element so the loop will not enter , but when the find method return null , may be the caller will throw NullPointerException if the caller don't know that this method will return null if the records not found or record don't match .

any thought ...

BR;
m_darim
SCJP, SCJD in progress B&S ...
 
Zeng Wei Chu
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


i think when there are no record to return , the best is to return an array of int value with zero size rather than null , becuase the caller for this method expect any array and he will loop on this array , if the array have no element so the loop will not enter , but when the find method return null , may be the caller will throw NullPointerException if the caller don't know that this method will return null if the records not found or record don't match .



Hi, agree with your view. This is a better return than null.
 
Simon O'Brien
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your ideas, I am not going to throw the exception.

As I will not be throwing any exception my find method will not actually throw a RecordNotFoundException exception as specified in the DBMain interface.

Would you leave the 'throws RecordNotFoundException' declaration in the implemented method declaration in the Data class (even though it is not thrown) or is it ok to remove it (as it is legal Java)?

I am worried about removing it because the coursework spec says: "Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:"



So would you declare the find method like ...




or would you declare the find method like ...



Thanks again.

Simon
 
Zeng Wei Chu
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Simon, I will follow exactly with the interface, as implementing clients will be expecting the RecordNotFoundException.
 
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
same.. after reading some posts, I think it is better to throw RecordNotFound since SUN provided it in the interface..
 
Simon O'Brien
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Great, that is what I was thinking, I just needed clarification! Thanks for all your help.

Simon
 
Ranch Hand
Posts: 288
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Simon O'Brien:
Great, that is what I was thinking, I just needed clarification! Thanks for all your help.

Simon



Hi Simon,

I think it is perfectly valid to drop the RecordNotFoundException from your implementation. Remember that clients should be using the DBMain interface reference type when interacting with your implementation class rather that a reference type of Data itself.

If clients are using a DBMain reference type as they should be, a client must be prepared to handle the exception regardless of whether or not your Data implementation actually throws it. I personaly feel it woul be bad priogramming practice to declare an exception to be thrown from a method when it never can be.
[ December 12, 2007: Message edited by: Mark Smyth ]
 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with you Mark, which is why I choose to throw RecordNotFound from my find method...

Do you throw "DuplicateKeyException" in your create method ? (its a dilemma if you use recNo as your key which easily leads to the impossibility of having a duplicate key.. (ex: key = maxRecNo + 1).

I don't know if I should still add the code to throw DuplicateKeyException and insert a comment stating that "it is currently not possible to meet this condition, but it is kept in order to support future modifications..."

Do you understand my point ? What's your opinion on that ?

Regards,
Alex
 
Mark Smyth
Ranch Hand
Posts: 288
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Alex Belisle Turcot:
I agree with you Mark, which is why I choose to throw RecordNotFound from my find method...

Do you throw "DuplicateKeyException" in your create method ? (its a dilemma if you use recNo as your key which easily leads to the impossibility of having a duplicate key.. (ex: key = maxRecNo + 1).

I don't know if I should still add the code to throw DuplicateKeyException and insert a comment stating that "it is currently not possible to meet this condition, but it is kept in order to support future modifications..."

Do you understand my point ? What's your opinion on that ?

Regards,
Alex



Hi Alex,

That is pretty much the same approach as I took to solve this problem. I think it is perfectly acceptable to drop the DuplicateKeyException from the create method and simply document your reasons for doing so.

Rgrds,
Mark
[ December 12, 2007: Message edited by: Mark Smyth ]
 
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

nice discussion. I think it makes sense to indicate the exception possibly being thrown since the interface declares it possible. I does not matter if your actual implementation of the interface method can throw the exception or not.

As a reference, look at the class java.io.StringReader, all the methods of which declare to possibly throw an IOException since this is declared possible in StringReader's super class java.io.Reader, no matter if the actual implementations of the methods can throw an IOException. A look at the code reveils that most of the method bodies cannot.

Cheers, Guido
 
Guido Sautter
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

nice discussion. I think it makes sense to indicate the exception possibly being thrown since the interface declares it possible. I does not matter if your actual implementation of the interface method can throw the exception or not.

As a reference, look at the class java.io.StringReader, all the methods of which declare to possibly throw an IOException since this is declared possible in StringReader's super class java.io.Reader, no matter if the actual implementations of the methods can throw an IOException. A look at the code reveils that most of the method bodies cannot.

Cheers, Guido
 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
uhmm.. I think you are right too Guido

Looking at my requirements, the only one related to this is the following:

=> Methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database.

Meaning, that the real requirement is not "must throw all Exception" but rather in which context RecordNotFoundException should be thrown.


So, then it depends if you think the situation in the find method fit with that statement or not..

Regards,
Alex
 
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my case (B&S) I throw DuplicateKeyException if already exist one record with exactly same values for "name" and "location".

and then I documented that in choices.txt

Regards.
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jose,

As I understand this, using name and location as a key might be a bad idea. Being that there is no room number column, if a specific hotel were to have multiple rooms available they would have the same name and location, but would truly be different entities.

All,

The way I read the requirements:

Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file.



I think we should throw RecordNotFoundException in the case of no matches (even though I agree returning an empty array would be a much better design) because the "specified record" clearly "does not exist", so the exception "should" be thrown. If they wanted to be really mean, they could have a test case that does a find that has no matches, and if RNFE is not caught, display result[0] without checking the length of the array.
 
The only taste of success some people get is to take a bite out of you. Or this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic