HaloO,

Darren Duncan wrote:
The problem is that $! is being treated too much like a global variable and not enough like a lexical variable. Consider the following example:

Wasn't the idea to have $! only bound in CATCH blocks?


  sub foo () {
    try {
      die MyMessage.new( 'key' => 'dang', 'vars' => {'from'=>'foo()'} );
    };

     CATCH {

    if ($!) {
      display_message( $! );
    }
    else {
      display_message( MyMessage.new(
        'key' => 'nuthin_wrong', 'vars' => {'from'=>'foo()'} ) );
    }

    } # end of CATCH

  }

Note that, while my examples don't use a CATCH block (which isn't yet implemented in Pugs), you get the exception from $! or an alias thereof anyway, so whether or not I used CATCH is factored out of the discussion at hand here.

Well, I think it brings us back to the discussion about the exception
semantics ;)
A CATCH block is not supposed to be executed under normal circumstances
and $! is undef outside of CATCH blocks. Your code mixes these two
things.


The big problem here is that almost any argument for any subroutine could potentially come from $!, and it would be rediculous for them all to be 'is copy' just to handle the possibility.

Oh, you are advocating exception handling while an exception is handled!
Thus after handling the exception exception the one-level-down exception
handler procedes normally exceptional again. Finally the normal,
non-exceptional layer is re-instated, or some such.


Nor is it reasonable for a caller to have to copy $! to another variable before passing it to a subroutine just because that sub *may* have its own try block ... a caller shouldn't have to know about the implementation of what it called.

I welcome feedback on this issue and a positive, elegant resolution.

I'm still advocating a semantic for exceptions that drop out of the
normal flow of events and call code explicitly dedicated to that task.
Returning to the normal flow as if nothing exceptional happened is
particularly *not* guarenteed! Thus the context of $! is *not* the
runtime context, just like the compile context isn't runtime either.

Actually, many of the exceptions might be compiled-in assertions that
where silenced warnings of the compiler: "didn't I say we'll meet again
:)".
--
$TSa.greeting := "HaloO"; # mind the echo!

Reply via email to