IOException is bugging me!

[Ray Cheeny]

Hi,
Now the IOException buggers me.In the Data constructor,it will throw IOExceptions.
My question is where to catch it in the server side and do you rethrow it to the clients?
I don't think the clent need to know it which the server dose not find the db.db
Could you tell me your design?
Thanks!

[Jim Yingst]

I catch it inside Data (the DB access class), wrap it in a DBException (a custom exception extending RuntimeException) and then re-throw it. I would prefer to use a checked exception, but my API does not allow it, and I don't believe that the other checked exceptions are truly appropriate for an IO exception. However many other people here re-wrap the exception in a RecordNotFoundException, which is allowed as a checked exception. Except in the find() method - I guess they just let find() return an empty array, while I prefer to have it throw an exception in case of IOException.
Note that different assignments have slightly different APIs, and so some of my comments may not apply to you. I'm doing the Contractors assignment, version 2.1.1. Read your own instructions carefully to see what they say.
[ July 16, 2003: Message edited by: Jim Yingst ]

[Ray Cheeny]

Hi,
I have factory in server side which 'return new RemoteAccess()'.In the RemoteAccess,the constructor invokes Data(Data data = new Data(dbFile)).When start the server, I will not know the exists of the dbFile until one client visit the server. In this situation, the server will throw IOExceptions(cannot find db).
So, could anyone tell me that need I recheck the dbFile,when start server?

[Jim Yingst]

Well, I don't know if you need to, but it seems like a good idea. If I were a server administrator and I had started a server, I would want to know right away if the DB file could not be found - not wait until my first client came along. However, this also depends on whether the client is allowed to specify the file name & path. See this for more discussion. (No feedback from Sun yet.)

[Ray Cheeny]

Hi Jim,
Another question,how to handle the InterruptedException in LockManager? If I throw it to the client,could you tell me how to describe the msg(show in the errorDialog).

[Jim Yingst]

That's up to you I suppose. In my program there isn't anything currently that should interrupt a thread (as opposed to notify()). So for the moment I'd treat any interrupt the same as I would an IOException or RemoteException (which is a kind of IOException anyway) - wrap it in a DBException, send it to the client, let the client say "something unexpected happened; can't complete your request, press this button to see the stack trace if you dare". However a reasonable future enhancement might be to add a timeout feature (some people do this now) - in this case, there's a good chance that the interrupt() indicates a timeout, so maybe the client could use Throwable's getCause() to see if the original exception was an InterruptedException, and then generate a more appropriate message. E.g. "you've been waiting for this record for too long. Give up and go have a beer. Try again tomorrow. Cheers..."

[Ray Cheeny]

Thanks,
But I still have two questions
1. I have the book method in the client.How about you? Which one is better,client or server?
2. This method return all the datas in some field.

  
 public String[] getFieldData(String fieldName) throws DatabaseException {
  if(getRecordCount>0){
    ...
    String[] record = data.getRecord(i + 1).getValues();
    fieldDatas[i] = record[j];
    return fieldDatas;
  } else
     throw new DatabaseException("N0 records in the database");
}

Is it redundant?
I just wonder 'data.getRecord(i + 1)' in Data will throw a DatabaseException, if there's no records.
a.just like the above
b.ignore it
c.catch the 'data.getRecord(i + 1)' and rethrow it.
How do you think about it.I don't how to deal with null value.

[Andrew Monkhouse]

Hi Ray

Jim: "you've been waiting for this record for too long. Give up and go have a beer. Try again tomorrow. Cheers..."

About 10 years ago a collegue of mine wrote a whole lot of error messages like that at the request of the client for some custom software (deadlock: "I'm stressed - please give me a moment to calm down, then try again"). They were exactly what the client wanted, but my manager had a fit when he finally got to see them

I have the book method in the client.How about you? Which one is better,client or server?

Ray - I believe you are working on Fly By Night Services. This makes a difference, as FBNS has the requirement: "The remote client code that you write must provide all the public methods of the suncertify.db.Data class.". Technically you could meet this requirement and additionally have a "book" method on the server, but I don't think that is a good solution because - why go to all the trouble of having methods exposed via RMI if you aren't going to use them?

2. This method return all the datas in some field. ....

I had something very similar in my solution. The only difference was that I only returned unique values for the given column - not all values.
I suspect with your code that if a record has been deleted then this method will throw a NullPointerException. Your code client side would also have to check for nulls in the returned array.
Regards, Andrew

[Jim Yingst]

"I'm stressed - please give me a moment to calm down, then try again"
[link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link]

I have the book method in the client.How about you? Which one is better,client or server?
I put mine on the client. That wasn't a requirement for my assignment, but I wanted to keep using the basic DB interface as much as possible to maximize reusability. Future enhancements will need read(), lock(), unlock(), update(), create(), and delete(), even though my GUI client only needs find() and book(). So the GUI uses a facade with the two methods it actually needs, but the network classes support the full "raw" DB interface.
The only reason I see to put book() on the server would be to cut down on network traffic. But (a) performance is not a bid deal here, and (b) most fo the network traffic probably comes from find() anyway - there's a lot of data being passed that way, compared to bookings. So there's insufficient incentive to put book() on the server, IMO.
Is it redundant?
Well, I'm not sure what the purpose is. As Andrew notes, you may want to return a set of unique values; it may also be nice if they're in alphabetical order. For this I'd probably use a TreeSet - just check if a value is null, and if not, put it in the TreeSet (which sorts itself for you, very nice).
[ July 16, 2003: Message edited by: Jim Yingst ]