I hope i'm not wrong, but i found only 2 methods that should be implemented in the server.
A find/search() and book(). am i right?
(i know it's possible to add other methods but that's not in the "must" list:
The user interface for this assignment must satisfy the following criteria:
• It must be composed exclusively with components from the Java Foundation Classes (Swing components).
• It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user. • It must present search results in a JTable.
• It must allow the user to book a selected record, updating the database file accordingly. )
since only these 2 methods are visible to the client, the client should only handle RemoteException and RecordNotFoundException, right?
(i still haven't decided how to handle the (virtually impossible) Security Exception. Either wrapping it in a RemoteException or make the
book method return a boolean that'll be false in this case)
Maybe you discover some other exceptions that could be thrown when implementing the book and find functionality. I would not handle SecurityException at all, because that would mean you as a developer has failed. In a well-tested application this exception will never occur.
yeah, i just remembered about the room already booked exception..
you are right (as usual ) but in java you must catch exceptions declared.
normally i would have left it empty but i don't think the assessor would think
it's a good practice. maybe i'll throw a remote exception and add a comment
/* not reachable statement */ or something like that
you could do it a RuntimeException. i didn't because i took the throw clause in the
interface provided as a hint that it's a checked exception. a runtime exception isn't
usually declared in a throw clause...
Jonathan Elkharrat wrote:a runtime exception isn't usually declared in a throw clause...
That's not completely true, certainly not if you take a look at commonly used frameworks like Spring, Hibernate, etc. Almost all the exceptions declared in method signatures are runtime exceptions (e.g. BeanFactory).
My interface does not declare this exception, so when a situation like the one you must throw a SecurityException occurs, I throw an IllegalStateException. In this scenario I would always prefer a runtime exception, because your code is not supposed to handle this kind of situation (it's a major bug and a user will not be able to recover from it). Which message will you show to the user, something like: "Dear user, due to a developer's mistake and the lack of testing by the user acceptance team you will not be able to book a room until this major bug gets fixed. We apologize for this inconvenience and hope we don't get fired"
maybe you saw it in other frameworks, but i'm pretty sure you cannot find it
in the J2SE source code...
what will i display to the user? maybe just "an error ocurred. please try again later".
(as with remote exception, which are checked exception too. this is why it made
sense to me to throw a remote exception in the catch clause, because both exceptions
cannot be handled gracefully in the client side..)
besides, the DAO methods could be called separatly by other programs and they
can split the lock/unlock calls, so from the point of view of the DAO it should be
a checked exception.. (the fact that your specific use of the DAO cannot rise this
exception shouldn't matter, i think)
Jonathan Elkharrat wrote:but i'm pretty sure you cannot find it in the J2SE source code...
I think that's true (so far I didn't encounter a runtime exception in java api)
Jonathan Elkharrat wrote:besides, the DAO methods could be called separatly by other programs and they can split the lock/unlock calls, so from the point of view of the DAO it should be a checked exception.. (the fact that your specific use of the DAO cannot rise this exception shouldn't matter, i think)
I don't agree here. If you should implement a fat client (instead of a thin client), this exception should never occur, unless someone of course tries to hack your application by purpose. But your program should never call the update/delete/unlock method unless it has successfully locked the record. And a record can be only locked by 1 thread at a time (other threads have to wait), so just 1 thread can successfully lock a record and get a cookie to perform update/delete and unlock.
there's some logic there.
an error that depend on the programmer is usually a runtime exception.
i checked the lock/unlock of the ReentrantLock class and guess what?
it throws an IllegalMonitorStateException - a Runtime exception.
looks like you were right....
once again your solution is cleaner and clearer...