// 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);
which will return a type of int as the array of mathched record ids. So in order to fully utilize the result, I am think I have to lock all records between the return of find() and my successively action of retriver records. Or the other way I have to cache all my records before find(). Is that true? Other question is in what situation should this find() method throws a RecordNotFoundException, I don't understand.
The fact that the method is declared as "throws RecordNotFoundException" simply means that you would be allowed to throw RecordNotFoundException, if you had a reason to - you're not compelled to do so. If they don't provide any other documentation about when this exception should be thrown (in the context of find()), you don't have to actually throw it.
but create() does - it has a DuplicateKeyException which I believe should not really be thrown. Others here disagree, and you can do a search on DuplicateKeyException to see many discussions of this, but my point is just that there is a significant possibility that Sun doesn't actually expect you to throw this exception. Give that possibility some thought
However I think you should seriously consider the possibilty of simply not throwing FileNotFoundException from find(), ever.
Originally posted by Jim Yingst:
I know that checked exceptions are generally viewed as a Good Thing, and I regret losing that benefit. However I'm not so enamored with them as many other people are; I'm willing to use unchecked exceptions if necessary.
Note that when doing something like this, using an unchecked exception when you'd rather be using a checked exception, I've found that it's useful during development to have the exception extend Exception rather than RuntimeException, so it's now a checked exception. This means that, for development only, the DB interface is also changed to include new exceptions. This lets you use the compiler to remind you where the exception may be thrown, and decalre it or handle it otherwise. Then just before final submission, change DBAccessException back to a RuntimeException, and replace the DB interface with the original version, which makes no mention of DBAccessException. But now all the other classes do document the excption, even though they don't have to, and probably handle it correctly, even though DB does not say anything about it. Admittedly, this won't prevent junior programmers from coming along later and screwing things up, now that it's no longer a checked exception - but at least the code that's submitted has a good chance of handling the exception correctly. Ought to be worth something at least.