Triggering an error on unsetting a traced variable

问题

I'm trying to create some read-only variables to use with code evaluated in a safe interp. Using trace, I can generate an error on attempts to set them, but not when using unset:

% set foo bar
bar
% trace add variable foo {unset write} {apply {{var _ op} { error "$var $op trace triggered" }}}
% set foo bar
can't set "foo": foo write trace triggered
% unset foo
%

Indeed, I eventually noticed the documentation even says in passing:

Any errors in unset traces are ignored.

Playing around with different return codes, including custom numbers, they all seem to be ignored. It doesn't trigger an interp bgerror handler either. Is there any other way to raise an error for an attempt to unset a particular variable?

回答1:

There really isn't. The key problem is that there are times when Tcl is going to unset a variable when that variable really is going to be deleted because its containing structure (a namespace, stack frame or object, and ultimately an interpreter) is also being deleted. The variable is doomed at that point and user code cannot prevent it (except by the horrible approach of never returning from the trace, of course, which infinitely postpones the death and puts everything in a weird state; don't do that). There's simply nowhere to resurrect the variable to. Command deletion traces have the same issue; they too can be firing because their storage is vanishing. (TclOO destructors are a bit more protected against this; they try to not lose errors — there's even pitching them into interp bgerror as a last resort — but still can in some edge cases.)

What's more, there's currently nothing in the API to allow an error message to bubble out of the process of deleting a namespace or call frame. I think that would be fixable (it would require changing some public APIs) but for good reasons I think the deletion would still have to happen, especially for stack frames. Additionally, I'm not sure what should happen when you delete a namespace containing two unset-traced variables whose traces both report errors. What should the error be? I really don't know. (I know that the end result has to be that the namespace is still gone, FWIW, but the details matter and I have no idea what they should be.)

回答2:

I'm trying to create some read-only variables to use with code evaluated

Schelte and Donal have already offered timely and in-depth feedback. So what comes is meant as a humble addition. Now that one knows that there variables traces are executed after the fact, the below is how I use to mimick read-only (or rather keep-re_setting-to-a-one-time-value) variables using traces (note: as Donal explains, this does not extend to proc-local variables).

The below implementation allows for the following:

namespace eval ::ns2 {}

namespace eval ::ns1 {
    readOnly foo 1
    readOnly ::ns2::bar 2
    readOnly ::faz 3
}

Inspired by variable, but only for one variable-value pair.

proc ::readOnly {var val} {
  uplevel [list variable $var $val]
  if {![string match "::*" $var]} {
    set var [uplevel [list namespace which -variable $var]]
  }

  # only proceed iff namespace is not under deletion!
  if {[namespace exists [namespace qualifiers $var]]} {
    set readOnlyHandler {{var val _ _ op} {
      if {[namespace exists [namespace qualifiers $var]]} {
        if {$op eq "unset"} {
          ::readOnly $var $val
        } else {
          set $var $val
        }
        # optional: use stderr as err-signalling channel?
        puts stderr [list $var is read-only]
      }
  }}

  set handlerScript [list apply $readOnlyHandler $var $val]
  set traces [trace info variable $var]
  set varTrace [list {write unset} $handlerScript]
  if {![llength $traces] || $varTrace ni $traces} {
    trace add variable $var {*}$varTrace
  }
}

}

Some notes:

This is meant to work only for global or otherwise namespaced variables, not for proc-local ones;
It wraps around variable;
[namespace exists ...]: These guards protect from operations when a given parent namespace is currently under deletion (namespace delete ::ns1, or child interp deletion);
In the unset case, the handler script re-adds the trace on the well re-created variable (otherwise, any subsequent write would not be caught anymore.);
[trace info variable ...]: Helps avoid adding redundant traces;
[namespace which -variable]: Makes sure to work on a fully-qualified variable name;

Some final remarks:

Ooo, maybe I can substitute the normal unset for a custom version and do the checking in it instead of relying on trace

Certainly one option, but it does not give you coverage of the various (indirect) paths of unsetting a variable.

[...] in a safe interp.

You may want to interp alias between a variable in your safe interp to the above readOnly in the parent interp?

来源：https://stackoverflow.com/questions/62846341/triggering-an-error-on-unsetting-a-traced-variable

标签

tcl