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