IOException in db find method

[Stephen Patrick]

Hi there

I have just being looking over my code and just wondering how all you java guru's out there handled IOExceptions in your find method of your Data class. The find method I must implement has the following signature
public int[] find(String[] criteria); as you can see it does not throw any Exceptions . Due to this fact if an IOException occurs for instance in my find method I simply ignore it and return a 0 length array to the caller. It's not a real big problem as it is unlikely to happen but could. I think it would be better to return an Exception that alerted the client to the fact an IOException occurs rather than a empty array.

Cheers

Stephen

[Javini Javono]

Hi,


public int[] find(String[] criteria); as you can see it does not throw any Exceptions.
Due to this fact if an IOException occurs for instance in my find method I simply
ignore it and return a 0 length array to the caller. It's not a real big problem as it
is unlikely to happen but could. I think it would be better to return an Exception
that alerted the client to the fact an IOException occurs rather than a empty array.


I'm not an expert, so I hope others will offer their opinions and advice.
For my project, my find method had this signature:
public int[] find(String[] criteria) throws RecordNotFoundException;

Your signature, which throws no exception, seems quite unique to me, though
others with more experience on this web site may consider it normal (see the
FAQ link above for possibly more information and method signature examples).

There appear to be two school of thought: throw an IOException as a runtime
exception of your own making, or throw the SunGivenException with the cause
being the IOException.

In your case, it seems that if you are to throw an exception, you have little choice
but to throw a RuntimeException of your own making: IORuntimeException,
for example.

The down-side is that no one is required to catch the exception once it is
thrown; but, there's nothing you can do about that given the interface you
have to work with.

Of course, regardless of what solution you eventually find to implement,
nothing stops you from printing or logging the exception to the terminal
window or the log.

Do your other methods throw any exceptions?

Here is an idea I just thought of, though I won't be changing my current
design and implementation to experiment with it.

Usually the specifications define, I think, at most two or three required
exceptions.

These create "problems" of different sorts: for instance, how does one
throw a RecordNotFoundException if the method only throws a
DuplicateKeyException, for example.

However, your unique signature made me think of a new idea. You can
define two methods: find() and search(). The find() method delegates
to the search() method and "swallows" all exceptions; afterall, if someone
really doesn't want to know if an exception occurred, perhaps, and you'd
have to be the final decision maker, but perhaps this is alright in this case.
Your search() method could be used to define your own, sensical exception
hierarchy; and, this would be particularly true if none of your methods
threw any exceptions. You would write your code to call search() assuming
that you did care about getting back reasonable exceptions to report to
the user.

Thanks,
Javini Javono
[ July 05, 2004: Message edited by: Javini Javono ]

[Stephen Patrick]

Thanks Javini for the advice. This is an interesting problem. I think I will throw a RunTimeException and document it, its not the best solution as you pointed out but at least I can catch it on the client and don't have to worry about breaking the contract in the db interface.

Yes all of my other methods in my interface throw exceptions see below.


Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:

package suncertify.db;
public interface DB
{
// Reads a record from the file. Returns an array where each
// element is a record value.
public String[] read(int recNo) throws RecordNotFoundException;
// Modifies the fields of a record. The new value for field n
// appears in data[n]. Throws SecurityException
// if the record is locked with a cookie other than lockCookie.
public void update(int recNo, String[] data, long lockCookie)
throws RecordNotFoundException, SecurityException;
// Deletes a record, making the record number and associated disk
// storage available for reuse.
// Throws SecurityException if the record is locked with a cookie
// other than lockCookie.
public void delete(int recNo, long lockCookie)
throws RecordNotFoundException, SecurityException;
// Returns an array of record numbers that match the specified
// criteria. Field n in the database file is described by
// criteria[n]. A null value in criteria[n] matches any field
// value. A non-null value in criteria[n] matches any field
// value that begins with criteria[n]. (For example, "Fred"
// matches "Fred" or "Freddy".)
public int[] find(String[] criteria);
// Creates a new record in the database (possibly reusing a
// deleted entry). Inserts the given data, and returns the record
// number of the new record.
public int create(String[] data) throws DuplicateKeyException;
// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.
public long lock(int recNo) throws RecordNotFoundException;
// Releases the lock on a record. Cookie must be the cookie
// returned when the record was locked; otherwise throws SecurityException.
public void unlock(int recNo, long cookie)
throws RecordNotFoundException, SecurityException;
}

Thanks again

Stephen

[Javini Javono]

Hi,

This is my own personal preference having almost completed this assignment,
so please feel free to ignore this advice if it does not resonate well with you.

In general, there being a couple exceptions, my exception hierarchy was all
checked exceptions, and one reason I really like this, is that you can then
leverage software tools to help you: the compiler tells you what exceptions
you need to check, Sun's doccheck tells you which exceptions you need to
document, and so forth.

Now, there are some reasons for run-time exceptions, of course, but I personally,
found great value in having the vast majority of my exceptions being checked
exceptions.

Let me try to rephrase this: if you find that you end up creating run-time
exceptions just to make the find() method happy, and then these run-time
exceptions start to "pollute" the other methods (where, let's assume, that
these are not run-time exceptions), then one possibility to consider is to
have find() throw no exceptions and make a search() method throw
reasonable exceptions, and find() delegates to search() and swallows as
outline previously.

Hopefully others might have good ideas on this topic.

Thanks,
Javini Javono
[ July 06, 2004: Message edited by: Javini Javono ]

[Philippe Maquet]

Hi Stephen,

I think it would be better to return an Exception that alerted the client to the fact an IOException occurs rather than a empty array.

I agree with you. As you, my findByCriteria() method doesn't throw any exception. So I used a RuntimeException (DataException) as a wrapper for the IOExceptions. Now to be consistent, I did the same in *all* Data methods, meaning that I don't use the provided checked exceptions as wrappers. See my reasoning here.

Regards,

Phil.