Hi William, by switching runtime exceptions back to checked exceptions, do you mean using DuplicateKeyException to wrap IOException in my example? By the way, IOException is not a subclass of Runtime exception.
"RuntimeException" don't have to be declare.Meaning, the interface provided by SUN forces you to declare/throw the "Checked" exception. Because of that Interface, you cannot throw any check exception other than what your Interface specifies.
However, RuntimeException (IllegalArgumentException, NullPointerException...Classes inheriting "RuntimeException") don't have to be declare and don't go against your contract.. Without being defined in your contract, you can throw them..
Having that said, it is good practice to define them in your implementation class (and since you are not allowed to modify your interface, you don't put it there..) Try it, create a method, don't declare any "throws". You'll still be able to throw "IllegalArgumentException" because it is a "RuntimeException".
Regards, Alex [ December 05, 2007: Message edited by: Alex Belisle Turcot ]
Alex Belisle Turcot
Joined: Apr 26, 2005
And I guess what William meant is: after catching the runtime exception (from the Object using his Data class), he creates a "normal" Exception (checked.. lets say Implementing "Exception"). Then, he throws this "checked" exception instead of throwing the runtimeException, which would be a little dirty!
Zeng Wei Chu
Joined: Dec 05, 2007
Hi Alex, many thanks for the clear explanation. How about RandomAccessFile operations which can possibly throw IOExceptions within the methods during creation, updating and deleting of records? There are a few possible solutions which I have thought of:
1) Use the declared checked exceptions to wrap it. For example, using the DuplicateKeyException to wrap IOExceptions during record creation process. However doing so does not quite justify the name of the DuplicateKeyException.
2) Declare a class which extends the RuntimeException. For example, using of CreationFailedException (a RuntimeException) to wrap the IOException. But is it correct to do it this way?
3) Catch the IOException in the create( ) method and log it. But the client will have no means of knowing that creation actually fails.
4) return -1 when IOException occurs. But the disadvantage would be coding will not be that readable.
Had been pondering over this IOException haha...headache. Are there any other ways to handle IOExceptions?