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 Sun, 04 Nov 2012 19:25:52 GMT
Hey Mike,

I'm not sure that I like the idea of throwing LuceneException or
SearchException everywhere. I've been there (long time ago) and I always
hated it.

First, what's the difference between 'new SearchException("Failed to read
the index", ioe)' and 'new IOException("Failed to read the index",
anotherIOE/anyE)'? Both don't give you any real way of detecting the
problem in your code, maybe only in the logs.

Perhaps you would like us to throw better IOE, i.e. rather than re-throwing
low-level IO exceptions, wrap them w/ another IOE w/ a detailed message.
That I can support, but do you have a concrete case where the exception
that was thrown was not descriptive enough?

For instance, there's that "read past EOF" exception which is annoying b/c
you can tell by the stacktrace where it happened, but not necessarily why
it happened. However, these are fairly low in our call stack, and I doubt
that even Lucene code itself can give meaningful messages to all low-level
IOEs. Yet, the exception does tell you that's usually an index corruption
case, or some other bug ... when Lucene detects the index is corrupt, it
throws the explicit CorruptIndexEx, otherwise, this must be inferred from
the stacktrace. Not perfect, but throwing IndexingException won't improve
it either.

So I'm +1 for making sure our exceptions are as informative as they can
get. I'm -1 for starting to throw LuceneException all over the place - to
me it's like IOE. Worse, if we start throwing LuceneException, people might
be tempted to wrap any Ex w/ LuceneEx, even ArrayIndexOutOfBound etc. I
don't want that.

If you've hit exceptions which could use better messages, I prefer that we
concentrate on them, rather than complicating the exceptions throwing
mechanism.

Shai

On Sun, Nov 4, 2012 at 7:25 PM, Michael-O <1983-01-06@gmx.net> wrote:

> Hi Simon,
>
> there are generally two very good resources how exceptions should be
> handled in Java. I will quote both:
>
> 1. Oracle's JavaDoc Style Guide: http://www.oracle.com/**
> technetwork/java/javase/**documentation/index-137868.**html#throwstag<http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#throwstag>
> 2. Joshua Bloch's book Effective Java, chapter 9:
> http://my.safaribooksonline.**com/book/programming/java/**9780137150021<http://my.safaribooksonline.com/book/programming/java/9780137150021>
>
> Am 2012-11-02 22:27, schrieb Simon Willnauer:
>
>  Hey,
>>
>> On Fri, Nov 2, 2012 at 2:20 PM, Michael-O <1983-01-06@gmx.net>
>> wrote:
>>
>>> Hi,
>>>
>>> why does virtually every method (exaggerating) throw an IOE? I know
>>> there might be a failure in the underlying IO (corrupt files,
>>> passing checked exc up, etc) but
>>>
>>> 1. Almost none of the has a JavaDoc on it
>>>
>>
>> what should the javadoc say? I mean it would repeat itself all the
>> time no?
>>
>
> At least one would know why this one is thrown. See source one.
>
>
>  2. Throwing an IOE from most of the methods doesn't really help.
>>> You cannot create separate catch blocks. You have to rip your code
>>> apart in tens of try catch blocks.
>>>
>>> Here is a simple example: Both IndexSearcher#search and
>>> IndexSearcher#doc throw an IOE with any further documentation. I
>>> don't have the chance to detect where the exception has happened
>>> nor I can pass something reasonable back to the user. And both
>>> methods are keypoints in Lucene.
>>>
>>
>> can you elaborate what you would change to make this easier
>> digestible for you? I mean specialized exceptions class would be a
>> mess here really.
>>
>
> Not only for me but for everyone.
>
> Generally, good exception handling should setup a simple exception
> hierarchy, not more than three levels. Two base classes for checked and
> unchecked exceptions. A main exception for a logical group like searching,
> retreival, query checking, etc.
>
> LuceneException
> |-- SearchException
> |-- RetrievalException
> |-- ...
>
> One should really wrap IOE in something like 'new SearchException("Failed
> to read the index", ioe)'. I would at least know that this one came from
> the index searcher.
>
> Really advisable are items 61, 62 and especially 63.
>
>
>  E.g., there are exceptions thrown in IndexSearcher without any
>>> message. Simply empty stubs.
>>>
>>
>> I agree we should fix them. I already committed some fixes to
>> IndexSearcher. Can you come up with a patch that fixes some more in
>> core?
>>
>> running grep -R "new.*Exception()" * | wc -l
>>
>> yields 82 in core so there is room for improvement.
>>
>>
>>> Lucene 4.0 received a complete API overhaul. Why was no action
>>> taken to clean up exception management?
>>>
>>
>> I'd really like to hear what you have in mind. can you elaborate?
>>
>
> 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.
>
> Lucene has already good exceptions like CorruptIndex, IndexNotFound,
> LockObtainFailed, etc.
>
> Of course, such a step would break backwards-compat but this is possible
> for 5.0 and this would require a general consensus of the devs improving
> this issue.
>
> I think that such a great framework can do better to inform programmers
> and users what has really failed especially if you design a public API.
> We have succeeded exceptional results with the Lucene framework. I am
> someone who likes giving help back to OSS projects.
>
> Hopefully, this is enough input for this message. We could discuss this
> further is there is a real interest from the devs.
>
>
> Mike
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.**apache.org<java-user-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: java-user-help@lucene.apache.**org<java-user-help@lucene.apache.org>
>
>

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