Exceptions

[GD Deepz]

Hi All,
B&S
Questioning on handling exceptions(chaining). I have a RecordNotFoundException class extends Exception which is thrown by an adapter class. The adapter class sits between the Remote class and the Data class providing the linkage(Adapter pattern-Facade). I also have a GUIException class on the client side that wraps the RecordNotFoundException object BUT I am unable to query the Exception object from the GUIException class.

Any feedback in escalating lower level exceptions to the GUI would be appreciated.

[Matt Sheehan.]

This should work as long as you do the following:

extend Exception for GUIException

have a GUIException(Throwable e) constructor with a call to super(e) or GUIException(String message, Throwable e) constructor with a call to super(message, e)

create the GUIException using: new GUIException(recNotFoundEx) or new GUIException(message, recNotFoundEx)

retrieve the original exception using: guiException.getCause() or the message using: guiException.getMessage()

HTH

Matt

[GD Deepz]

Thanks Matt, man I despise this interface Sun gave -- DBAccess, I realize it was done on purpose to get us to think BUT I am spending most of time structuring my app around this stupid interface-- unproductive time-- does not happen in the real world. Do I really have to use all its signatures or can I just get the Data class to implement it and not use it at all.

[peter wooster]

Originally posted by GD Deepz:
Thanks Matt, man I despise this interface Sun gave -- DBAccess, I realize it was done on purpose to get us to think BUT I am spending most of time structuring my app around this stupid interface-- unproductive time-- does not happen in the real world. Do I really have to use all its signatures or can I just get the Data class to implement it and not use it at all.

You must provide access to your database using that interface, so Sun can use it to do automated testing of your database and locking code. You could have your Data class implement another more reasonable interface that the methods in DBAccess call on to do the real work. An adapter is a better choice. I've chosen to use the DBAccess interface and use a unchecked (Runtime) exception to pass things like IOException and RemoteException over to my client. I put the actual exception in the cause and then interpret that once it gets to the GUI. I use two Adapter patterns that are inverses, resulting in a Proxy.

So in the standAlone mode:
Business -> DBAccess(Data)

and in network mode
Business -> DBAccess(DataProxy) -> DataAdapter -RMI-> DataAdapterImpl -> Data

both DataProxy and Data implement DBAccess, DataAdapter adapts Data to provide RemoteException. DataProxy adapts DataAdapter to remove the RemoteException. Thus DataProxy is a real proxy, ie an adapter that does not change the interface.

There are lots of other ways, its up to you to pick one, and justify it in your choices document.

And this sort of stuff does happen in the real world, especially when you are dealing with existing code in a maintenance environment or integrating a third party library. You may wish to rewrite the interface, but doing so may end up causing months of work for a group with no time available in their work registry, or who think your project would be best if it were never completed, and throw all sorts of stupid restrictions in your path. Its also possible that the interface is part of a third party application that you don't have code for or the code is proprietary and you can't modify it for legal reasons (our case).

[GD Deepz]

Thanks Peter, will consider your input. In my real world, I take user functional requirements and trnspose into a design and into code which I control. Most of my clients do not tell me waht interface to use. Well that is my world. I am still wrestling with this interface from hell