Thank you for your contribution. I assume you are referring to the second part of my question - what to do to avoid these problems?

Object oriented programming/design (OOP/D) may be part of the answer, but in and of itself, it isn't the answer. The module in question is implemented as a class and the handler variable in OO terminology is class data. Simply putting a veneer of OO over a poor design doesn't solve the design problems. In this case the OO interface was probably an after-thought. Based on the internal source code documentation it appears that the original implementation might have had a functional, rather than OO interface. My guess is that the global handler is a hold over from that earlier implementation, and not an intentional choice to make something class level data.

But, in a general sense, I agree with you. Had the original author used an object method/object data for the customization rather than global handler (class data), the various trade-offs discusssed in my original post could have been avoided. Extensions wishing custom error handling would simply subclass the original module. The mechanism used to select method implementations for objects would have insured that the right handler got matched with the right extension subroutines. There would have been no need for a begin block+localization (see my reply to tilly) to do this manually and much less reason to be concerned about conflicts.

However, even had a method been used, that isn't the end of the story. In the sample code for my reply to tilly, I arranged things so that at least two different custom handlers were involved. In an OO solution, that could translate into at least three different designs, and possibly more:

• three overridable methods - a default handler method and two custom handler methods.
• a default method handler and a customization hash - the customization hash would mapped subs to custom handlers so that the user would have full control over which methods got assigned which custom handlers
• a combination of the first two - the customization methods would provide default behavior when the customization hash was missing an entry for a particular subroutine.

The choice of which is best isn't something that can't be made in the abstract. The hash is more likely to be stable, but may be more complexity than end-users want. The customization methods may be easier for end-users, but the scope of the problem may ultimately outgrow that solution. The mixed approach requires richer testing and more implementation time.

Best, beth

Update: various clarifications