Re: What is the best way to extend packages with global error handlers?

Also, is there a more stable Perlish way to allow some measure of customization for error handling?

In general, Perl Best Practices (Chapter 13, "Error Handling") recommends throwing exceptions rather than returning special values or setting flags and, in particular, endorses the CPAN Exception::Class module.

Comment on Re: What is the best way to extend packages with global error handlers?

Replies are listed 'Best First'.
Re^2: What is the best way to extend packages with global error handlers? by ELISHEVA (Prior) on Feb 23, 2009 at 09:30 UTC
Thank you for looking that up. Throwing (rather than returning exceptions) is definitely a good idea, however, it won't solve this particular problem or create a more stable customization interface. The default implementation of the global error handler does just that, throw an exception, politely, with `croak` no less. The problem I was struggling with isn't how to pass the exception (return value, throwing), but rather (a) how best to work with the way this particular module chose to support customization of the throwing behavior (b) how to support customization of hooks (error handlers or others) without creating the issues presented by a global handler. Best, beth	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: What is the best way to extend packages with global error handlers?
by ELISHEVA (Prior) on Feb 23, 2009 at 09:30 UTC

The default implementation of the global error handler does just that, throw an exception, politely, with croak no less. The problem I was struggling with isn't how to pass the exception (return value, throwing), but rather (a) how best to work with the way this particular module chose to support customization of the throwing behavior (b) how to support customization of hooks (error handlers or others) without creating the issues presented by a global handler.

Best, beth

[reply]
[d/l]