Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

update and delete shouldnt throw RNFE?

 
Jason Then
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ranchers,

In a previous post (http://www.coderanch.com/forums/posts/list/40/427863#2237145) Roel says that update, unlock and delete shouldnt throw RNFE.
I just wanted to expand on this a little further.

So Roel's reasoning is that the client should have first locked the record to do an update, unlock or delete.

I agree that unlock shouldn't throw RNFE - because a client may have locked, then deleted a record.

However, what about the case where we have a *dumb* client.
What if the client which owns the lock decides to delete a record, then tries to delete the record again or update it after deleting it? Shouldn't these cases throw RNFE?

Cheers,
Jason
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jason,

That's not a "dumb" client, but a serious bug from a developer. And such code should never pass through testing (could be easily found when making test cases using EasyMock for example). If the API is used correctly, a correct sequence is lock, update (or delete) and unlock. Of course that's just my opinion. Your update/delete methods may throw the RNFE, even your unlock method may do that. I documented my decision thoroughly and apparently the accessor was quiet happy with it

Kind regards,
Roel
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic