GeeCON Prague 2014*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes RecordNotFoundException directly extend RuntimeException? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "RecordNotFoundException directly extend RuntimeException?" Watch "RecordNotFoundException directly extend RuntimeException?" New topic
Author

RecordNotFoundException directly extend RuntimeException?

Anne Crace
Ranch Hand

Joined: Aug 29, 2005
Posts: 223
Anyone pass with this approach? After days of searching, I am still confused on this. I think most wrapped it in another RuntimeException(IllegalStateException for instance). I am doing my final checks and documentation before uploading my project, and want to feel a bit more confident on this matter. Here is my explanation in choices.txt as it stands right now.
RecordNotFoundException - I throw this if the given record is marked as deleted,
and only on an update of an existing record. If the record is to be updated, it
should theoretically exist. I keep a map of records marked as deleted, and if
the given record to be updated matches a record in the deleted map, the
exception is thrown. I have this exception extend RuntimeException because the
above scenario is the only instance that it will ever be thrown. Since the
client interface can only reserve rooms, (write is only performed on the owner
field), outside of testing, this situation will never happen. The instructions
say "should", not "must", so I don't throw it every time it does not exist or
is marked deleted. In the instance of a search returning nothing,
I display a message to the user stating nothing matches the search criteria.
There is no reason to stop the application because a search returned no valid
data. This situation is easily recoverable by allowing a new search.

I am using the "reuse deleted records" suggested in the interface for createRecord() should they exist. If no deleted, I write beginning at EOF.


SCJP, SCJD
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5300
    
  13

Hi Anne,

I find it a very weird approach. Only throwing the RNFE with an update of a non-existing record And what with a read, a delete or a lock of a non-existing record?

I followed completely another approach: my application throws the RNFE (being a checked exception by the way) from the following methods: read, find, lock and isLocked. For the find-method you could also use of course null or an empty array.

Anne Crace wrote:I have this exception extend RuntimeException because the
above scenario is the only instance that it will ever be thrown. Since the
client interface can only reserve rooms, (write is only performed on the owner
field), outside of testing, this situation will never happen.

I think putting something down like this in your choices.txt will make you lose some points because what about future enhancements?

Kind regards,
Roel


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Anne Crace
Ranch Hand

Joined: Aug 29, 2005
Posts: 223
You have helped me find yet another logic error in my code. Thank you for that Good point about future enhancements. I know you chose to extend from Exception, which I did do for my SecurityException, but I am going to beg to differ from you on this, and take the other path on RecordNotFoundException. There is a right way to do it and a wrong way to do it, and I know others have passed with the Runtime approach, but I'm not sure if they wrote RNFE to directly extend RuntimeException, or if they declared it to extend Exception and then wrapped it in another RuntimeException (most likely IllegalArgumentException)
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5300
    
  13

Hi Anne,

Don't gonna argue about if the RNFE should be a checked or a runtime exception, because that's your choice and there is no right or wrong.

I found it useful to make it checked, mainly to enforce the handling of the exception, because it is an error of which your program should be able to recover from (notify user the record he's trying to read/update is already deleted). The exception handling (with the checked exceptions) is a very powerful feature of the java kanguage, but if you have to many checked exceptions or use them wrongly, it could have the opposite effect.

Personally I don't see any benefit (nor common sense) in making your RNFE a checked exception and then wrapping it in a RuntimeException and throwing the runtime exception, while the signature of the read-method indicates that this method could throw a RNFE. So that's just bad and poor design.

And as a final question: why did you make your SecurityException a checked one? Because I believe that exception should only be thrown if a record is for example updated by another client that's not owning the lock on that record. And so if you have designed and developed your application to work as described in the requirements, this exception will never be thrown. If it is thrown, your locking mechanism has a flaw and your program can't recover from it (and thus should not be handled too). If you made a programming error in the locking mechanism, it should be noticed in the testing phase. If it's discovered when your program is in production, your program becomes useless and you will have to release a patch or a new version.
I didn't have such a SecurityException, but if in my program a record was updated by a client not owning the lock on that record I throw an IllegalStateException and I never handled that exception throughout my application, because in a well-written application this kind of exception should never occur!

Just my 2 cents.
Kind regards,
Roel
Anne Crace
Ranch Hand

Joined: Aug 29, 2005
Posts: 223
My code passes Roberto Perillo's famous locking test plus a couple junit tests that I found on here. Never see any evidence of a SecurityException thrown or caught. It is only unlock() that should throw it. From what I've read in my many searches, I think notifyAll() takes care of that. I do get some RecordNotFoundException on deleted records, but that is OK for his test. Here's a good thread on the SecurityException argument.SecurityExceptionThread
 
GeeCON Prague 2014
 
subject: RecordNotFoundException directly extend RuntimeException?