aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S Appropriate Use of Exception Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S Appropriate Use of Exception" Watch "B&S Appropriate Use of Exception" New topic
Author

B&S Appropriate Use of Exception

Simon O'Brien
Greenhorn

Joined: Nov 21, 2007
Posts: 7
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

Joined: Nov 21, 2007
Posts: 7
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
Zeng Wei Chu
Greenhorn

Joined: Dec 05, 2007
Posts: 27
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


SCJP | SCJD | SCWCD | SCBCD | SCEA
mohamed sulibi
Ranch Hand

Joined: Sep 04, 2005
Posts: 169
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

Joined: Dec 05, 2007
Posts: 27

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

Joined: Nov 21, 2007
Posts: 7
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

Joined: Dec 05, 2007
Posts: 27
Hi Simon, I will follow exactly with the interface, as implementing clients will be expecting the RecordNotFoundException.
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
same.. after reading some posts, I think it is better to throw RecordNotFound since SUN provided it in the interface..
Simon O'Brien
Greenhorn

Joined: Nov 21, 2007
Posts: 7
Great, that is what I was thinking, I just needed clarification! Thanks for all your help.

Simon
Mark Smyth
Ranch Hand

Joined: Feb 04, 2004
Posts: 288
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 ]

SCJP<br />SCJD
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
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

Joined: Feb 04, 2004
Posts: 288
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 ]
Guido Sautter
Ranch Hand

Joined: Dec 22, 2004
Posts: 142
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

Joined: Dec 22, 2004
Posts: 142
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

Joined: Apr 26, 2005
Posts: 516
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
Jose Luis Iturbide
Ranch Hand

Joined: Jul 21, 2007
Posts: 73
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.


JLuis Iturbide
SC(JP|JD|WCD|BCD|EA5.0), OC(PJP7|MJEA6) - Blog: http://jiturbide.blogspot.com/
Lucas Theisen
Greenhorn

Joined: Jan 16, 2008
Posts: 3
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.


Thanks,<br />Lucas
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: B&S Appropriate Use of Exception