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
Ranch Hand
Joined: Dec 03, 2003
Posts: 286
posted
0
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 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
Ranch Hand
Joined: Dec 03, 2003
Posts: 286
posted
0
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.
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.
0
. Due to this fact if an 
