lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trejkaz <>
Subject Re: Excessive use of IOException without proper documentation
Date Mon, 05 Nov 2012 02:30:16 GMT
On Mon, Nov 5, 2012 at 4:25 AM, Michael-O <> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message