B&S: Reading a deleted record - best way to handle this

[Aaron John]

My interface for read is

public String [] read(int recNo) throws RecordNotFoundException;

If a client calls the read method with a given recNo, the read method has to check whether the record is flagged as deleted. When encountering a deleted record, is it necessary to throw a RecordNotFoundException? e.g.

int deletedFlag = database.readUnsignedShort();
if (deletedFlag == DELETED_RECORD) {
    throw new RecordNotFoundException("Record Not Found");
}        

I'm in two minds about this. If my client tries to read a deleted record, some sort of exception from the data layer should be sent to the client, indicating that the record is deleted, hence a RecordNotFoundException.

On the other hand, my find method also calls the read method, and throwing the RecordNotFoundException to my find method forces the find method to handle the exception - in this case, the find method would just ignore the exception (ignore any deleted records). To me, this isn't good use of RecordNotFoundException.

Does anyone have any thoughts on proper ways it should be implemented?

[Chih-Wei Lee]

Hi John:
I think you should adopt your first solution
cuz according to the instruction:
"Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file."
So if client read a deleted record, a RecordNotFoundException should be thrown.

[Jason Moors]

Hi Aaron,

A possible solution if you don't want to handle the RecordNotFoundException in your find method is to create a new private method for actually reading the record which doesn't throw an exception, this method would return null array if the record is not found or marked as deleted.

private String[] readRecord(int recNo)

This new method would then be called by both the read and find, the read method would check if the returned value is null and throw a RecordNotFoundException, and the find method could ignore null array and not add to search results.

Hope it helps,
Jason
[ June 23, 2008: Message edited by: Jason Moors ]

[Ronggen Liu]

Hi guys,

exactly, there is no deleted records in my application implementation, i didn't retrieve the deleted records when get the all records initially.the exception RecordNotFoundException in read method just will be throw out when there is no the record in my storage list, which holds all the records except deleted records.

Thank you!
Ronggen

[Aaron John]

Originally posted by Jason Moors:
Hi Aaron,

A possible solution if you don't want to handle the RecordNotFoundException in your find method is to create a new private method for actually reading the record which doesn't throw an exception, this method would return null array if the record is not found or marked as deleted.

private String[] readRecord(int recNo)

This new method would then be called by both the read and find, the read method would check if the returned value is null and throw a RecordNotFoundException, and the find method could ignore null array and not add to search results.

Hope it helps,
Jason

[ June 23, 2008: Message edited by: Jason Moors ]

Okay, for example in the read method, the read method will need to read the actual database file, but these kind of operations may throw an IOException. How would you handle the IOException so that it doesn't propogate to calling methods?

[Jo�o Batista]

Think about the kinds of Exception that a method can throw and how they affect the method signature.
You'll find a way to disguise that IOException.

[Aaron John]

Originally posted by Jo�o Batista:
Think about the kinds of Exception that a method can throw and how they affect the method signature.
You'll find a way to disguise that IOException.

Hi Joao,

I could not follow your previous post. Could you give me an example please?

Thanks.

[Jethro Borsje]

Originally posted by Aaron John:


Okay, for example in the read method, the read method will need to read the actual database file, but these kind of operations may throw an IOException. How would you handle the IOException so that it doesn't propogate to calling methods?

You can also choose to read the data file into memory before hand, the Data class would then just hold a Map of the records in memory. Using this approach you do not have any IOExceptions during the usage of the Data class. You can catch these errors before hand we reading the file into memory. In my opinion this is also better, because you may not want th DB server to run at all if some serious IOExceptions occurred.

[Aaron John]

Originally posted by Jethro Borsje:


You can also choose to read the data file into memory before hand, the Data class would then just hold a Map of the records in memory. Using this approach you do not have any IOExceptions during the usage of the Data class. You can catch these errors before hand we reading the file into memory. In my opinion this is also better, because you may not want th DB server to run at all if some serious IOExceptions occurred.

Ah okay, that is a good approach. Thanks for that. How often would one read the database in order to have the latest records in memory?

[Jethro Borsje]

Originally posted by Aaron John:


Ah okay, that is a good approach. Thanks for that. How often would one read the database in order to have the latest records in memory?

I believe you can assume that there is only one server which uses the data file at any time, so just reading the file in memory at startup of the server would be enough.

I have not implemented this approach entirely in my application, because I still have to find a way to make sure we save the data in memory back to the file. We should do this when the server is being shutdown, but we should also make sure we do not lose to much data when the server crashes. Perhaps saving the data file every x seconds / minutes is a good approach here?

[Jo�o Batista]

Originally posted by Aaron John:


Hi Joao,

I could not follow your previous post. Could you give me an example please?

Thanks.

There are other threads mentioning this subject. A popular trend here is to use RuntimeException to deal with that error.