So for example, the caller runs: my::Error::register('my::Plugins::ThisPlugin::miHandler') but the name of the real sub is myHandler...
Then you should call my::Plugins::ThisPlugin::miHandler. If it throws an error, so be it. If you want to catch the error, use eval BLOCK or whatever module you prefer.

I can't do that, because I can't call their error handler unless I get an error! It would be very incorrect to just call the handler "as a test". Certainly when I do call their handler I absolutely run it in an eval block and catch any undefined reference there.

What I'm trying to do is validate that the sub name is correct and real at registration time, because the input they're giving is only very rarely used (only when a bad error occurs) and so it's quite possible that they could not notice the typo. Yes, of course, all these types of failure scenarious SHOULD be tested, but I prefer to implement defensive programming and fail immediately on the register if the argument I was given is bogus.

Is it possible?

That said, it might make more sense to register the package, then always call a specific method of that package (say ->handle_error()).

Actually I can't do that either: some of these plugins have very complex error conditions and they register multiple error handlers, as the plugin proceeds and makes more changes, and they expect the handlers to be run in the proper order. Further, the same plugin can be called multiple times during the invocation, with different contexts, and this requires different cleanup operations.

There are lots of options here of course, that involve more work by the plugin writers to consolidate all that into one error handler and keep their own internal state (which would need to be cached to disk--remember what I'm trying to implement is a way to "restart" the process after kill -9 or power failure). I can easily come up with these alternatives. However, the method that I have today is powerful and perfect for my needs and for the plugin authors' needs, and I really don't want to rewrite the error handling API and push a lot more work onto them: I want to continue to manage it for them inside my framework, and keep the framework easy to use and robust in the face of misconfiguration.

Thanks!

In reply to Re^4: Saving/recovering sub refs in a file by madscientist
in thread Saving/recovering sub refs in a file by madscientist

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • 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! —
  • 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:
    & &amp;
    < &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.