I have this exception handling framework for my FBN assignment. please let me know if Iam on the right direction. I have a common super-class ApplicationException for all Application related exceptions. The subclass types under this category are: DatabaseException - related to Database access ServerException - any exception in the Server code FrontendException - any exception in the Client code ValidationException - user input validation The client code on catching an exception passes the exception object to the ExceptionHandler object. The handler distinguishes between the application exceptions and system exceptions (RemoteException, NamingException, ....) and creates a dialog box to present the appropriate exception message description. The ApplicationException object has the error code describing the problem, which is used by the handler to retrieve appropriate message descriptions from a java properties file. Also, I need to modify the Data class to throw a DatabaseException wrapping up the IOException instead of IOException alone. is this acceptable ? because, the requirement says the Data class is already complete except lock,unlock and criteriaFind. please let me know your comments. -venky
Hi Venkatesh Interesting aproach. I think it should be quite good.
Also, I need to modify the Data class to throw a DatabaseException wrapping up the IOException instead of IOException alone. is this acceptable ? because, the requirement says the Data class is already complete except lock,unlock and criteriaFind.
As you noted: the provided classes are identified by Sun as being complete. Personally I don't think we should change them. If this was a real life application, then the client may already have other applications which use the Data class - if we change the exception then their existing applications will not run. Likewise remember that your instructions tell you that your client application "should include a class that implements the same public methods as the suncertify.db.Data class". So I think that you would have to catch the IOException somewhere in your client code and re-throw it as a DatabaseException if you really want to have only DatabaseExceptions. Personally I think it may be easier just to process the IOException in your exception handler. Regards, Andrew
Hi Venkatesh: The exception organization by subsystem is interesting, but I'd question if it really follows the spirit of exceptions. My take on the issue is: (1) Exceptions should be handled where it is most reasonable to resolve the problem. I wonder if a ServerException shouldn't by definition be resolved by the server. One might pass "server couldn't start" or similar exceptions to a system level handler, but "RecordNotFoundException" as well? (2) Exceptions should be meaningful to the handler. For example, the "RecordNotFoundException" makes sense if one is doing a readRecord(). But, does readRecord() expect to get a ServerException? I'm conflicted here, I like the architectural structure being imposed, and think that helps organize the system. But, is this applicable to exceptions? Looking through SUN's exceptions, I found the RemoteException and SQLException that sort of indicate subsystems. But the caller explicitly calls those. In the case of the ServerException, the server might get a DatabaseException when it tries to perform an action. So, what does ther caller see when, for example, a record isn't found: a ServerException, a ServerException chaining a DatabaseException, a DatabaseException, or a DatabaseException chaining a RecordNotFound? Thanks for raising an interesting issue! Tx
posted 17 years ago
Hey Bob, --------------------------------------------------(1) Exceptions should be handled where it is most reasonable to resolve the problem. I wonder if a ServerException shouldn't by definition be resolved by the server. One might pass "server couldn't start" or similar exceptions to a system level handler, but "RecordNotFoundException" as well? -------------------------------------------------- My exception design thought was something like this: The FBN system constists of Frontend, Server, and a Database. any database calls should expect a DatabaseException (similar to SQLException for all database exceptions) and ServerException. ServerException is like RemoteException where it's too generic to bind to a specific problem but thrown by the Server system. currently, in my FBN assignment, I don't see any need for a ServerException. but I need a framework. As Andrew mentioned that I can't change the Data class to use my exception handlig framework. I need to think abt another way of handling it. what do you think ? -venky
BEA 8.1 Certified Administrator, IBM Certified Solution Developer For XML 1.1 and Related Technologies, SCJP, SCWCD, SCBCD, SCDJWS, SCJD, SCEA,
Oracle Certified Master Java EE 5 Enterprise Architect
posted 17 years ago
Hi Venkatesh: My assignment is URLyBird, which requires local and remote database server modes. I assume FBN also requires remote. What I did was create a server interface and implement it at the client using the Proxy Pattern. The server implements the interface directly (the server has a HAS-A relationship to the Data object). Then polyphorphism is used for the local/remote calling. The Proxy calls the remote object, which contains a server object. This permits me to present any exception that I want to the user (I use exception chaining to pass the exception remotely) and leave Data unchanged. Exception chaining has the problem that the chained exception isn't identified in the throws construct, so the caller needs special information to de-chain. This results in a documentation challenge. However, my only chained exception occurs at the RMI remote object, so the problem is limited in scope. Tx