[hibernate-dev] "plugin loading" in Hibernate Search

[Sanne Grinovero]

cool, fast answers! opened HSEARCH-384

I'll see what I can do about the context-dependent error messages, I'm
experimenting
with a String parameter to add some "component description", but I
have yet to verify if
it's enough for all cases.

2009/6/30 Emmanuel Bernard <emmanuel at hibernate.org>:
> Yes go ahead. The hard part is to provide a meaningful error report
> which depends on the context.
>
> On Tue, 2009-06-30 at 14:50 +0200, Sanne Grinovero wrote:
>> Hi,
>> the code of Hibernate Search is very extensible, as nearly all
>> internal modules are "overridable" by user provided implementation;
>> this external classes are loaded by defining a short name (in case of
>> built-in extensions) or fully qualified names to load
>> whatever is on the classpath to replace internals.
>> For some issues I'll soon have to be copy-pasting the usual exception
>> handling code around, again..
>> A quick regex count on the code base reveals that this same code is
>> duplicated in other 25 places, mostly correct but sometimes
>> forgetting to handle one or two cases (for example ClassCastException
>> is not handled often)
>>
>> I am building a util class to get some consistency, and plan to unit
>> test this extensively to make sure it throws understandable exceptions
>> for the most common mistakes (hey, I need a public no-args
>> constructor! / not implementing the X interface! / ...)
>> -> DRY, improve error messages.
>>
>> would this be a good moment to apply such a refactoring? I don't need
>> to replace all cases, but would like to apply it on most,
>> or at least the new code going to be written.
>>
>> Should I change all use cases I can find? I like consistency, not conflicts.
>>
>> greetings,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>