Hello All, This a pre-flight, i.e. before submission, check-up. I have two "severe" exceptions defined. One is called MagicCookieException and the other is called FatalSystemException. Both extend the RuntimeException and are being thrown in the Data class. MagicCookieException is thrown in the constructor of the Data class if the Magic Cookie value read from the header of the RandomAccessFile does not match the "hard-coded" constant magic cookie value in the Data class. FatalSystemException is thrown in the lock method if we somehow end-up getting the InterruptedException thrown. I catch the InterruptedException and rethrow the FatalSystemException with an appropriate message to be displayed to the user. I am using exception chaining mechanism new to JSDK 1.4.x for chaining both these exception and catch them in the GUI layer to display appropriate message to the user. Everything works well. I have these two exceptions in a separate package called "suncertify.exceptions". My reasoning is that since these exceptions are being shared by the Data class and in the "suncertify.db" package and the GUI layer in "suncertify.gui" package, they belong in a separate package. But now I am having second thoughts due to the following statements in the given instructions:
Any unimplemented exceptions in this interface must all be created as member classes of the suncertify.db package. Each must have a zero argument constructor and a second constructor that takes a String that serves as the exception's description.
I am not sure if the above statements apply to the MagicCookieException and FatalSystemException? These are special-case exceptions that are thrown under severe circumstances. They also have four constructors instead of two. The remaining two constructors are used by the exception-chaining mechanism. Mind you, I am defining the RecordNotFoundException and DuplicateKeyException in the "suncertify.db" package above with a zero argument constructor and a second constructor that takes a String that servers as the exception's description. My question is: should I move both MagicCookieException and FatalSystemException into the "suncertify.db" package or leave them in the "suncertify.exceptions" package where they currently reside? Appreciate your thoughts. Regards. Bharat
Hi Bharat, Any unimplemented exceptions in this interface This statement reffers only exception from DB interface. It doesn't reffer your own defined exceptions. There is no way I want to confuse you, but I have decided to make my exceptions thrown in C-tor as checked exceptions, not Runtime ones. E.g. an invalid Magic cookie is not an implementation error, so it should be a checked exception. Best, Vlad
My question is: should I move both MagicCookieException and FatalSystemException into the "suncertify.db" package or leave them in the "suncertify.exceptions" package where they currently reside?
MagicCookieException for sure. Because it's an exception that no other method except those in the db package may throw. Let's say that if suncertify.db.MyClass.MyMethod() is the only one which may throw your MagicCookieException, it makes more sense that MagicCookieException is defined in suncertify.db. As far as FatalSystemException is concerned, the question is : is that exception thrown only from your from suncertify.db package (1) or from another package too (2) ? If (1), suncertify.db is a better place, and if (2) suncertify.exceptions is a good one. All that IMO. Best, Phil.
posted 16 years ago
Hello Vlad/Phil, Thanks for your responses. Phil, I will move both the exceptions in the "suncertify.db" package. Regards. Bharat
Come have lunch with me Arthur. Adventure will follow. This tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop