jQuery in Action, 2nd edition*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Methods implemented in the server Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Methods implemented in the server" Watch "Methods implemented in the server" New topic
Author

Methods implemented in the server

Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170


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. )

second question:
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)


SCJP 5, SCWCD 5, SCBCD 5
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5132
    
  12

Indeed, just these 2 methods.

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.


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

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
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5132
    
  12

Jonathan Elkharrat wrote:but in java you must catch exceptions declared.

Not true, only checked exceptions must be handled or declared.
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

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...
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5132
    
  12

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"
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170



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)
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5132
    
  12

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.
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

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...
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

just a side note:
if it's a runtime exception you can remove it from the class that implement the interface.
(but i think i'll left it anyway, just so the assessor will see it )
 
 
subject: Methods implemented in the server
 
Similar Threads
Misc URLyBird questions not covered in the assignment instructions
Should I remove those search criterion other than name+location
NX:JTextField squeeze into funny size -- help!!
Do I have to supply a "Delete" button in GUI?
MVC