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
