Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S: Exception handling in book method in adapter

 
Derek Canaan
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
What do you think of this idea:
1. The book method only throws one exception, BookingException (BX).
2. BookingException extends Exception
3. Unwrap any exceptions from Data and re-wrap them in BookingException
4. Send only BookingException to GUIController

This simplifies the BookContractor in GUI:

Comments, anyone?
thanks,
derek
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11945
212
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Derek,
It does simplify your coding for now, but it makes the assumption that you will not be trying to do any recovery in the GUI level.
For example, if the book method failed because of a network error, then the user might want to retry (and after they have hit retry twice, they will get sick of it and talk to the administrator). But you no longer have that option - all errors are BookingExceptions, and all you can do is report on them.
You have to decide whether there is anything that you are wrapping in a BookingException that you might want to handle - if not, then you can ignore this comment.
Regards, Andrew
 
Derek Canaan
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
[Andrew]: but it makes the assumption that you will not be trying to do any recovery in the GUI level.

Some of the BookingException(msg) has msg that advises the user to try again (ie. click the book button again). Is such "recovery" good enough?
Or do you mean programmatic recovery?

If i do not have any programatic recovery, is having one Booking Exception for the adapter's book() method ok?
Could you also comment on the finally block on unlock. The goal is to release lock on the record in the event of an exception thrown during the lock/re-read/update/unlock process. What if unlock itself throws exception? The lock for that record will still be locked and never released. Is this right? If so, is there any way to unlock? What about programmatic recovery and try a few more times as shown below:


thanks in adv,
derek
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11945
212
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Derek,
Originally posted by Derek Canaan:
If i do not have any programatic recovery, is having one Booking Exception for the adapter's book() method ok?

Should be fine.
Originally posted by Derek Canaan:
Could you also comment on the finally block on unlock. The goal is to release lock on the record in the event of an exception thrown during the lock/re-read/update/unlock process. What if unlock itself throws exception? The lock for that record will still be locked and never released. Is this right? If so, is there any way to unlock? What about programmatic recovery and try a few more times as shown below:

The problem with the auto retries is that if the record cannot be unlocked due to a network problem (or because the client application crashed) then this still won't help you.
Now you may not have to worry about client / network crash in order to meet the minimum requirements for this assignment. But if you do want to think about it to make a more robust solution, then you might want to look at the Unreferenced interface on the server site: that way your server will get notified if the client is no longer connected and can clean up any stale locks.
Regards, Andrew
 
Derek Canaan
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
The problem with the auto retries is that if the record cannot be unlocked due to a network problem (or because the client application crashed) then this still won't help you

Mine is a 3-tier design where the unlock is done at the server side. In the event of network problem or client crashed, the server side still tries to unlock the record. This is useful so that other remote clients can book that record. It would not help *only* if the design is 2-tier. Is this so or am i missing something?
.. look at the Unreferenced interface ... clean up any stale locks
This is scary - i'm almost done with the minimal requirements and this is actually the next thing i might consider.
Currently, i have only *one* RemoteAdapter bound to the rmiregister.
To clean-up stale locks, i need:
  • a factory to dish out one adapter to each remote client
  • a collection in each client to keep track of all records it has locked
  • RemoteAdapter implements Unreference
  • codes in unreferenced method to iterate over collection and call unlock

  • Is this right? Have i left out anything? If my design is 3-tier and if my analysis above is correct, would it make all these codes unnecessary?
    rgds,
    Derek
     
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander
    Pie
    Posts: 11945
    212
    C++ Firefox Browser IntelliJ IDE Java Mac Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Derek,
    Sigh. I keep assuming that people are developing fat clients. Then all my comments are blown out of the water. :roll:
    You are right - since you are developing a thin client solution, then you do not need to worry about cleaning up stale locks.
    Regards, Andrew
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic