lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <ser...@gmail.com>
Subject Re: Excessive use of IOException without proper documentation
Date Mon, 05 Nov 2012 07:49:45 GMT
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 <trejkaz@trypticon.org> wrote:

> On Mon, Nov 5, 2012 at 4:25 AM, Michael-O <1983-01-06@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message