I agree with adrianh, your problem is not that the Exceptions aren't been caught -- the problem is that you changed the "API" of your code. You're clients had a contract with you, that in an error/exceptional condition, you would do "foo" (presuably return undef, or false, or something like that) and then all of hte sudden you changed the rules on them, and started throwing exceptions -- so your program dies, which is what it's supposed to do if the exception/error isn't caught.

What you can do, is take advantage of the caller function to determine if a try call is anywhere in the call stack at the moment you encounter an error, and if so then use throw, otherwise just return undef.

If you're paticularly crafty, you can make a subclass of [cpan://Error] that overrides the throw function to do all the work for you, and anytime it encounters an exception with no try in the stack trace, it can not only tell it's caller to return undef, it can log hte full strack trace with args to some special system wide log file which you can audit on a regular basis to track down code paths that don't include exception handling. once you're satisfied that you've done a full migration to the new world order, you can remove your overridden throw function (so that you have an empty subclass) and lose the slight performance penalty.

(This is something Iused to long for in java, a "warn" method that takes a "Throwable" and only throws it if someone upstream wants to catch it -- hence in situations where you are interested in knowing about every instance of MildlyAnoyingButNotCritialException, you can put a try block upstream that catches it, but in the cases where you really don't care you can trust the method you are calling to do the right thing and plod along past whatever situation would normally cause the MildlyAnoyingButNotCritialException)

Update:

  1. It just occured to me that [id://Abigail-II] and i suggested roughly the same thing, but with different implimentations.

  2. While coming home from work, it occured to me that you don't have use caller to walk the stack, there's a simpler way to do it, that gives you finer control over detecting what exceptions people are catching, and which they aren't...

    You can use Perl's dynamic scoping, to have a "global" hash keyed on exception types. Then in your new subclass of "Error" override the "try" method to local that hash, and set true values for any Exception types that you have catch clauses for. In your overriden "throw" method, you check that hash, and if the exception you want to throw "isa" any of hte keys in that hash, go ahead and throw it -- otherwise log that the exception would not be caught, so you are defaulting to the old behavior.

In reply to Re: Enforcing exception catching by hossman
in thread Enforcing exception catching by dmitri

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.