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