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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev