I think that specific exceptions should be thrown only in case we expect the user to do something with it. E.g. LockObtainException is something that I can catch and try to recover from in the code, maybe retry to obtain the lock.
But all IOExceptions, maybe excluding FNFE, are unrecoverable in the sense that there's nothing that you can really do in your code, besides re-throwing it. I agree with TX - it would have been better if we just threw IOError, but I don't think it's necessary to change the API at this point. As long as Lucene throws IOE with meaningful messages, which will be informative for logging, I'm ok with that. If there are exceptions that are thrown with obscured messages, let's fix them. And yes, let's make sure that Lucene doesn't throw *only* IOE. I.e., if there's code that needs to throw an Exception, and it chooses IOE just because the rest of the code throws it, then that's wrong. IOE should indicate IO errors. Most of Lucene code is low-level enough to trip on IO errors. But if there's a QueryParser code that never does IO, then it should pick a proper exception to throw. That's my preference, others may disagree. In the end, as Dawid put it, these are different viewpoints, there's no right or wrong. As long as we're consistent and informative, our API will be in good shape. Shai On Mon, Nov 5, 2012 at 4:30 AM, Trejkaz <trej...@trypticon.org> wrote: > On Mon, Nov 5, 2012 at 4:25 AM, Michael-O <1983-01...@gmx.net> wrote: > > Continuing my answer from above. Have you ever worked with the Spring > > Framework? They apply a very nice exception translation pattern. All > > internal exceptions are turned to specialized unchecked exceptions like > > AuthenticationExceptoin, DaoAccessException, etc. > > I quite like unchecked exceptions. I think that checked exceptions > have their place as a special return value, but once you're out of the > one method which has the special return value, all other exceptions > should really be unchecked. It wouldn't be so bad if it weren't for > Java's compile-time checking that you have caught them. (A lot of the > time you're dealing with parallel execution or caching APIs and the > existence of a single checked exception means you now really do have > to catch Exception...) > > IOException in particular is just awful, in my opinion. Everything > which does I/O throws the exception, even though in tons of cases, the > only thing which can cause it to be thrown is hardware failure, > unplugging a disk or some rogue user going through and marking all > your files read-only. All of these scenarios to me are along the same > lines as running out of memory, yet OutOfMemoryError is an Error while > IOException is a checked Exception. > > They realised their mistake and started to introduce IOError for these > unexpected situations, but the APIs which already throw IOException > are probably poisoned for life. > > I understand that there are legitimate cases of IOException, such as > FileNotFoundException when trying to open a file which doesn't exist. > But that is certainly not the sort which Lucene is propagating out > through its API (or if it is, it shouldn't be.) > > As far as what users of Lucene are doing, in our case we're catching > any IOException Lucene throws and wrapping it in an unchecked > exception. If anything goes wrong with stores it's a pretty > catastrophic situation which we won't be able to recover from anyway. > And because IOException is being thrown with no additional > information, it's not like we can make use of the information in the > exception even if we caught it. > > TX > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > >
