in reply to RFC: Lexical Fatal.pm for Perl 5.10

  1. With regard to naming:

    Roget's says: "use fatal for something which has caused someone's death; use lethal for something which is capable of killing someone."

    So maybe use lethal; makes more sense.

  2. With regard to the interface. It would be nice if the lexical module took care of installing and backing out the exception handler. It's not onerous work, but is ripe for automation. Something like: 
    {
    use lethal qw[ ... ], sub {
        if( $^exception eq 'something' ) {
            ## deal with it
            ...
            return;
        }
        else {
            die $^exception; ## re-throw
        }
    };
    ...
    ## protected code here
}

    [download]

    Ie. The module would save the current $SIG{__DIE__} handler and install a the users callback and restore the original when leaving scope or when no lethal; is seen.

    I'm not sure all of that is possible, never mind how to do it. But I like the idea of it.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^2: RFC: Lexical Fatal.pm for Perl 5.10
by pjf (Curate) on Mar 09, 2008 at 08:47 UTC
    maybe use lethal; makes more sense.

    I love the suggestion. Thank-you! Project named internally to 'lethal'. ;)

    It would be nice if the lexical module took care of installing and backing out the exception handler.

    While I appreciate the desire here, I'd argue that lethal is the wrong place to do it. I expect most Perl developers are used to seeing exception handling occur at the bottom of code. In traditional Perl 5: 

    eval {
    scrub($decks);
    weigh($anchor);
    sail_to($destination);
};

if ($@) {
    warn "Uh oh, we had a problem with $@";
}

    [download]

    Or when using the Error module: 

    use Error;

try {
    scrub($decks);
    weigh($anchor);
    sail_to($destination);
}
catch Error::Anchor with {
    my $E = shift;
    warn "The anchor's stuck due to $E";
} otherwise {
    my $E = shift;
    warn "We're not sailing due to $E";
};

    [download]

    In both cases (and in most languages), the exceptions are handled at the end, or in the calling code. I'd certainly be surprised to see the exception handler before the code that may throw the exception.

    However I will be mindful to ensure that lethal inherits cleanly, so this can be implemented easily in a child module if you think it's a good idea. ;)

    Many thanks for the excellent ideas,

    Paul Fenwick
    Perl Training Australia
[reply]
[d/l]
[select]
      In both cases (and in most languages), the exceptions are handled at the end, or in the calling code.

      Well, if you use the $SIG{__DIE__} = sub (...) approach, this has to be done up front. The two approachs, signal handler and block eval serve slightly different purposes, but can be mixed I think.

      Anyway, good luck with your module :)

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

In Section Meditations