This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Questions about Data class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Questions about Data class" Watch "Questions about Data class" New topic
Author

Questions about Data class

Seer Awad
Greenhorn

Joined: Oct 02, 2005
Posts: 3
Hello
A firend of mine told me about this site, and I am glad to know about it 'cause I quickly found the answers to many questions. this is my first time to post a question and I hope it is meaningful . I still have some problems regarding the following:

1. I like the idea of wrapping the I/O Exception in a RuntimeException, but then should I attempt to catch this Runtime Exception when I invoke Data method from my server? In case we should, how should I deal with it? Ignore it? Or may be just let it go uncatched and therefore terminate the application?
2. Should I call unlock() from within the delete method? I guess I should beacuse if I don't then I will break the sequence lock-delete-unlock, where the unlock method will always throw RecordNotFoundException. What worries me is that, the delete method is declared to throw that same Exception, which means that the sequence lock-delete-delete should throw A RecordNotFoundException since I didn't unlock the record yet. Please firends help me with this.

Thank You
Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

Hello, and welcome!
I like the idea of wrapping the I/O Exception in a RuntimeException

Personally , i dont like that. I think it breaks the aim of exceptions. You are hiding those exception cases to the clients of the class.

Anyway there are methods in the interface where you have no chance, so they not throw any checked exception.

I decided wrapping into method checked exceptions where it's possible and into runtime exceptions in those cases.


Should I call unlock() from within the delete method?

Are you calling lock() from within it?...

Symmetry is a measure of beauty


SCJP, OCMJD, OCMJEA
Seer Awad
Greenhorn

Joined: Oct 02, 2005
Posts: 3
Hello,
Thank you Oricio for your warm reply, it really feels good. Back to business:
I decided wrapping into method checked exceptions where it's possible and into runtime exceptions in those cases.

can you explain your strategy more.

I do not call unlock from within the delete method. I want to preserve the sequence lock-delete-unlock, the invokation of unlock shouldn't throw RecordNotFoundException, otherwise the user will be bugged with this exception evertime a record is being deleted and then unlocked. I scanned this forum and found a thread regarding the unlock() method where a similar question is posted. He suggested that the RecordNotFoundException thrown from the unlock method is an indication that the record in not locked in the first place, and I somehow can sense some logic in this:

When we lock a record, a RecordNotFoundException is thrown if the record doesn't exists. Logically, the unlock() method should never throw that Exception since the lock() method guarantees the record existence before it's being locked. This dilemma raises the follwoing scenarios:

1. unlock() method should throw RecordNotFoundException if the record doesn't exists in the database file, (that means we will never be able to unlock records that we locked, and then deleted coorectly)
consider this scenario:

I think that sounds more like it. what do you think Oricio?

Seer
Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

Hello again Seer,

invokation of unlock shouldn't throw RecordNotFoundException ...

Yes, i agree but, i cant understand what the problem is

literally my specs:


My unlock method doesn't throw RecordNotFoundException, maybe your specs are quite different.

Anyway here is my design:

None of my DBAccess methods implementation calls internally lock or unlock
I think this is obvious for update, or delete due to the cookie argument.
Reading methods also don't need locking at all: readRecord, findByCriteria.
The special case is createRecord, in this case, the client doesnt what record to lock so there are two (at least) posibilities: lock internally or synchronize its access.

In resume, my data class provides locking service. But it's client responsability or better, requirement, to use it.

I do not care about orphaned locks

I implement a bussiness layer (server side) to provide booking services.

Hope this help you...
regards
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Seer & Oricio,

Originally posted by Seer Awad:
I like the idea of wrapping the I/O Exception in a RuntimeException

Originally posted by Oricio Ocle:
Personally , i dont like that. I think it breaks the aim of exceptions. You are hiding those exception cases to the clients of the class.

Anyway there are methods in the interface where you have no chance, so they not throw any checked exception.

I decided wrapping into method checked exceptions where it's possible and into runtime exceptions in those cases.
Doesn't this mean that you might have the same cause throw two different exceptions? That is, if you have a corrupted database (for example), and it is the read() method that comes across the corruption then you might wrap the IOException inside a RecordNotFoundException, but if the corruption occured while calling the find() method, you might wrap the IOException in a Runtime Exception?

Also - in that example I just gave, if there was data corruption resulting in an IOException, is it appropriate to throw it in a RecordNotFoundException? Consider if the corruption occurs after record number 10 - a client tries to read the record, gets back a RecordNotFoundException - so they might assume it has been deleted and go on to book record number 5: you have now made the problem worse, because you are still storing bookings in a corrupted table.

Originally posted by Seer Awad:
I like the idea of wrapping the I/O Exception in a RuntimeException, but then should I attempt to catch this Runtime Exception when I invoke Data method from my server? In case we should, how should I deal with it? Ignore it? Or may be just let it go uncatched and therefore terminate the application?
If you do not catch it in the Server code, then the thread that is handling that particular client's request will terminate, however the server itself could continue running.

I would recommend you consider what should happen from both a client and a server perspective if an IOException occurs. Again - think of my example where the database is potentially corrupt - what do you want the server to do? Do you want to tell the client anything? Just crashing the application is probably not the most user-friendly option here.

Originally posted by Seer Awad:
invokation of unlock shouldn't throw RecordNotFoundException ...

Originally posted by Oricio Ocle:
Yes, i agree but, i cant understand what the problem is [...] maybe your specs are quite different.
Highly probable. Take a look at the JavaRanch SCJD FAQ, particularly the question on "How may assignments are there?".

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

Hello ranchers,


Originally posted by Andrew Monkhouse:
Consider if the corruption occurs after record number 10 - a client tries to read the record, gets back a RecordNotFoundException - so they might assume it has been deleted and go on to book record number 5: you have now made the problem worse, because you are still storing bookings in a corrupted table



Andrew, here you are assuming that the cause of the IOException is an irreversible corruption in data file, in that case i agree with you, the problem would be too severe for only throwing a RecordNotFoundException and continuing with the normal execution.

But, can't an IOException be thrown due to a transient problem?
In that case it's reasonable throw a new recordNotFoundException (theIOException.toString()) don't you think?

Maybe a good point will be checking (or trying to check) file integrity each time an IOException is thrown...

Am i overthinking the problem?

Regards
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Questions about Data class
 
Similar Threads
locking and RecordNotFoundException
Design of data access layer - please comment on
B&S: Locking
B&S Data exceptions
NX: About data consistent