• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S: What if client doesn't have lock?

 
Michal Charemza
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I have searched for an answer to this, but I couldn't find one. My specification states that the lock() method in DBMain should lock a record so that it is only updated or deleted by this client.

What should the update()/delete() methods do if this client doesn't have the lock?

It could throw a RecordNotFound exception (as it is specified in the interface), but it seems a bit "dodgy" to throw this in this case since the record may be there, just that the client doesn't have permission to access it.

Michal.

p.s. I last looked at this a year ago. There is a chance I have already posted this question then. However to search for my posts I need my member number, and to get that I need to post something (I can't find it my profile). If this is the case - sorry!
 
Paul Bourdeaux
Ranch Hand
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Michal,

I am assuming that the interface in your assignment version does not throw a SecurityException...

I believe the most popular solution in the past has been to create a custom exception that extended RuntimeException, and throw it that way. You still need to make sure you catch it in your client code though...

Search the forum for "no SecurityException" and you will find pleanty of discussion regarding this. Here is one of many links I found dealing with similar issues.
 
Michal Charemza
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Paul Bourdeaux:
Hi Michal,
I am assuming that the interface in your assignment version does not throw a SecurityException...

Yes you're right.

After doing a few searches on "SecurityException" and following your link, this does appear to be a descision between either extend RuntimeException (as you say) or a wrapping (i.e. chaining) exceptions (a similar decision as with IOException for file i/o) I will look through the threads and think about it.

Thanks for your very quick reply,

Michal.
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What should the update()/delete() methods do if this client doesn't have the lock?

From the purist point of view, the update()/delete() methods should not be checking for locks at all. To take it a bit further, these methods should not even know what a "lock" is. The responsibility of update()/delete() methods should be just that -- to know how to update and delete the records in the database. This concept of separation of the responsibilities is a bit tricky to implement if your requirements state that you must also implement the lock()/unlock() methods of the same class, but it's still doable. One possible way is to leave the implementation of these methods empty, and instead put it in a dedicated class. A more compromizing method would be just to delegate locking/unlocking to another class. Either way, update()/delete() methods would not be checking for locks.

Some ranchers would take dim view of such a creative workaround in respect to the assignment requirements, but the alternative is also unpleasant -- either change the Sun-specified method signature to allow it throwing a checked exception, or pretend that you really like runtime exceptions and throw one of those instead.
[ June 02, 2005: Message edited by: John Smith ]
 
Michal Charemza
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the general concensus (and the one that I, at least at the moment still, agree with) is not to change the Sun-specified method signature, but to somehow use it "as best I can", i.e. throwing a RuntimeException as you say (or wrapping it... but I think for unlock() throwing a runtime is best).

Michal
 
Uwe Schäfer
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hmmm... if deleting without providing a proper lock is a misuse of the documented API, isn�t this a proper situation for throwing IllegalStateExc. or IllegalArgumentExc. ?

(don�t have a clue of your method signature)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic