• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Exceptions

 
GD Deepz
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Ranch Hand
    Posts: 55
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 1033
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 55
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
     
    It is sorta covered in the JavaRanch Style Guide.
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic