• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Exceptions

 
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
      Number of slices to send:
      Optional 'thank-you' note:
    • 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.
     
    Ranch Hand
    Posts: 1033
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic