wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Never throw exception that SUN declares Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Never throw exception that SUN declares" Watch "Never throw exception that SUN declares" New topic
Author

Never throw exception that SUN declares

Mingwei Jiang
Ranch Hand

Joined: Feb 19, 2004
Posts: 63
In my DB interface, the unlock method also throw RecordNotFoundException. I think it's reasonable for the lock and some other methods to throw this exception, like read, update, delete, because it is reasonable to first verify the existence of the record, then lock it or do some modification on it. But why unlock method need to throw RecordNotFoundException? I put locked records in a hashmap, and if unlock(recNo, cookie) is called, I'll check if the recNo is in the hashmap, if not, it will simply return, otherwise, it will remove the recNo in hashmap and return. I just don't know why bother throwing this exception. trying to verify the existence of the record will possibly cause IOException and maybe lower the performance.

I want to ask can I never throw this exception in code, though it was declared by SUN?
Julian Kennedy
Ranch Hand

Joined: Aug 02, 2004
Posts: 823
Hi Mingwei,

My spec for B&S states that you MUST implement the interface. Bearing that in mind I wouldn't want to omit the exception even if I could justify it in my design choices. The worst case scenario is that it could cost you 150 bucks (or whatever) to resubmit!

I think there's a good reason to have the exception anyway. If your app is trying to unlock a record that isn't locked then that's surely an error condition, though perhaps not a very serious one. If you don't find the recNo in the HashMap, just throw the exception. No big deal. Your calling code can then just catch it and quietly log it as a warning, if you choose.

How does that sound?

Jules
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Mingwei Jiang:
In my DB interface, the unlock method also throw RecordNotFoundException. I think it's reasonable for the lock and some other methods to throw this exception, like read, update, delete, because it is reasonable to first verify the existence of the record, then lock it or do some modification on it. But why unlock method need to throw RecordNotFoundException? I put locked records in a hashmap, and if unlock(recNo, cookie) is called, I'll check if the recNo is in the hashmap, if not, it will simply return, otherwise, it will remove the recNo in hashmap and return. I just don't know why bother throwing this exception. trying to verify the existence of the record will possibly cause IOException and maybe lower the performance.

I want to ask can I never throw this exception in code, though it was declared by SUN?


My interface doesn't require that, but I suppose if you did
lock
delete
unlock
there is some justification when doing the unlock to throw a RecordNotFound, many real systems unlock records immediately on deletion, so no unlock call is needed. It really depends on whether you are dealing with locking of actual records or the locking of numeric resources. In my project the LockManager only locks numeric resources, the Data class checks for record existence on methods that require it.
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Julian Kennedy:
Hi Mingwei,

My spec for B&S states that you MUST implement the interface. Bearing that in mind I wouldn't want to omit the exception even if I could justify it in my design choices. The worst case scenario is that it could cost you 150 bucks (or whatever) to resubmit!

I think there's a good reason to have the exception anyway. If your app is trying to unlock a record that isn't locked then that's surely an error condition, though perhaps not a very serious one. If you don't find the recNo in the HashMap, just throw the exception. No big deal. Your calling code can then just catch it and quietly log it as a warning, if you choose.

How does that sound?

Jules


RecordNotFound does not mean that the record wasn't in the Map, it means its either outside the file or has been deleted.

If its not locked anymore, my code would throw a SecurityException. Oddly the documentation for that exception is also suspect. For updateRecord it says "throws SecurityException if the record is locked with a cookie other than lockCookie" while for unlock it says "Cookie must be the cookie returned when the record was locked, otherwise throws SecurityException." The documentation for unlock is clear, but the documentaion for updateRecord doesn't specify what action to take if the record isn't locked at all.
Julian Kennedy
Ranch Hand

Joined: Aug 02, 2004
Posts: 823
Hmmm, good point Peter! Good job you were paying attention.

Looking at my interface, the unlock() method does throw a RecordNotFound exception though it doesn't say under what circumstances it should be thrown (perhaps that's [incorrectly] assumed to be self-evident).

However, as you demonstrate with your "delete" example, it's clearly a nonsense. So, my intention is to implement the interface as it is and then simply document that RecordNotFound in never thrown by unlock(), stating the reason.

Now I come to think about it I think I've seen that conclusion on an earlier thread elsewhere on this forum. Wasn't up to that point at the time though.

Jules
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
I find in my project I have to resort to exceptions where any error causes my program to not execute something very important. I have to do this since there is no other good way to make the error known to higher-level functionality. RecordNotFoundException fits into this scheme quite well.


Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Anton Golovin:
I find in my project I have to resort to exceptions where any error causes my program to not execute something very important. I have to do this since there is no other good way to make the error known to higher-level functionality. RecordNotFoundException fits into this scheme quite well.


I don't use RecordNotfound for things other than being unable to find a record. There are plenty of IOExceptions that need to be thrown, but can't because they are checked exceptions and are not declared. I also have exceptions such as FileFormatException that are checked exceptions.

What I've done with these, all of which are fatal to the server is to wrap them in a RuntimeException that I've called DataException. This takes an exception as an argument, allowing chaining. eg.


This can be caught at higher levels such as the network or business layers and the cause can be extracted and rethrown. In my case, I'll catch it and shut down the database, since these all indicate a corrupted file. Once the database shuts down the network will break all connections and the server operator will be prompted for a new database file.
Julian Kennedy
Ranch Hand

Joined: Aug 02, 2004
Posts: 823
Peter's solution is an option that I have considered in my design (which I haven't implemented yet). Of course what we really want to do is to use checked exceptions. Clearly we can't change the DB interface, but can we use checked exceptions without changing it?

Is this code legal?

I only ask as I don't have access to a Java compiler here to check it out myself.

Jules
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Julian Kennedy:
Peter's solution is an option that I have considered in my design (which I haven't implemented yet). Of course what we really want to do is to use checked exceptions. Clearly we can't change the DB interface, but can we use checked exceptions without changing it?

Is this code legal?

I only ask as I don't have access to a Java compiler here to check it out myself.

Jules


no, that doesn't compile, you get overridden method does not throw java.io.IOException

The popular choice other than what I suggest is to extend the exceptions that the interface supports and use something like


then use that to wrap the IOException. This works everwhere except for the FindByCriteria which doesn't throw any exceptions.

There was very long thread last year discussing this, I'll see if I can find it. They suggested at least 6 solutions. I'm not certain my solution is safe, since it could crash an automated testing program, so I might adopt one of the others.

Is there anyone who has passed using runtime exceptions to wrap the IOExceptions?
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Here's that very long thread from last year.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Never throw exception that SUN declares
 
Similar Threads
Locking strategy with singleton
B&S : Exception
B&S: locking in try/finally block
pls validate my locking strategy - all inputs are g8ly appreciated. (URLyBird)
Questions about Data class