http://qs321.pair.com?node_id=673102


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

I object to your "exceptions" pragma. You are not powerful to prevent any exceptions from being generated by a snippet of code. To truely do that, you must eval wrap all possible functions and opcodes in that scope including the builtin ones and eat all runtime errors. A declaration like "no exceptions" is highly categorical and probably isn't the kind of guarantee that you can sanely promise. It certainly goes beyond your intent of merely affecting the "Fatal" module. Try to stay away from overreaching language when designing your API.

To be able to say "no exceptions" you need to prevent perl from throwing exceptions in addition to exceptions explicitly written in user code. Examples of runtime code that you'd need to handle are method calls on undefined values, blessing into references, sort routines returning non-numbers, etc. It would be possible to disable all possible exceptions but it seems like it's hard. I'd reserve such strong statements until and unless you can actually make those kinds of guarantees.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

  • Comment on Re: RFC: Lexical Fatal.pm for Perl 5.10

Replies are listed 'Best First'.
Re^2: RFC: Lexical Fatal.pm for Perl 5.10
by pjf (Curate) on Mar 10, 2008 at 00:43 UTC
    I object to your "exceptions" pragma.

    Do you object to the whole idea, or just the name? The idea is nothing new, we're doing exactly the same thing as Fatal, but on a lexical scope. In other words, open() is simply turned into open() or die under the hood. If you think that Fatal is a good idea, but this pragma is a bad one, then I'm very interested in hearing more of your reasons why. My biggest problem with Fatal was always that it had too wide a scope.

    As per BrowserUk's suggestion, I've renamed the pragma to lethal, avoiding the confusion that a statement like no exceptions may cause. no lethal simple disables the effects of the lethal pragma. Things can still throw exceptions, our pragma just won't have been the cause of them.

    I hope this solves your objection to the name; if it doesn't, then I've misunderstood your node, and I'd love you to elaborate.