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.

Should I change all use cases I can find? I like consistency, not conflicts.

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