I'm working with a CPAN package that has decided to make its error handling customizable via a global variable storing an error handling subroutine. I'm really not sure how to best to extend the package and would like your collective wisdom.

I need to override the default handling because the default version returns a localized error string. In my extension I need to make my error handling conditional on the type of error. I don't want to trap and parse locale specific strings to guess the type of error. Fortunately the underlying API has locale independent error constants I can use instead. However, I only have access to those constants if I provide my own error handler.

Now here is the dilemma: if I set the global variable for the error handler sub directly (no localizing), then I run the risk of clashing with other CPAN modules I might want to use that also set the global variable. I also risk clashing with any consumer code of my module that wants to set their own handler. They may throw an error object I don't expect or I may throw an error object they don't expect. Neither is a "good thing".

If I localize the variable that stores the error handler, my extension is insulated from clashes, but now I've violated the user's expectation that they can customize error handling any way they wish. I don't like changing documented features.

So what is the best way to handle this? - do I

• localize and explain to the user that he/she can't define their own exception handling anymore?
• localize and define some new variable to hold a new handler and call that new handler whenever my localized handler is done doing what I want to with the exceptions? This preserves some ability to customize but still changes expectations.
• use the global variable and degrade gracefully (with warnings) when someone tries to define an error handler that throws something my code doesn't understand. This would keep my code from breaking, but could be very annoying, especially if another package really *needs* an error handler that does something different.
• use the global variable and document what constitutes clashing handlers? This would mean that we would have to investigate every related 3rd party module for potential clashes. And as a matter of principle, I don't like writing fragile code.
• some other solution I haven't thought of?

Also, is there a more stable Perlish way to allow some measure of customization for error handling? I think all of the above choices are lousy and would rather not put someone in the position of having to choose amongst them for any module I write.

Many thanks in advance, beth

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.