It is important to be aware of which of the trap mechanisms is in place to avoid unintended interactions, and aware of which conditions may cause a switch-over from one mode of error handling to the other.

Whenever a SET command is executed that assigns a value to either $ZTRAP or $ETRAP, the value of the other error handling variable is examined. If the other value is non-empty, an implicit NEW command is executed that saves the current value of that variable, and then the value of that variable is set to the empty string. After this, the requested assignment is made effective.

For example, re-setting $ETRAP is internally processed as:

	NEW:$LENGTH($ZTRAP) $ZTRAP SET $ETRAP=code	
	

Whereas, SET $ZTRAP=value is internally processed as:

	NEW:$LENGTH($ETRAP) $ETRAP SET $ZTRAP=value
	

Note that NEW of $ETRAP or $ZTRAP implicitly sets the value of the empty string after saving the prior value. As a result, at most one of the two error handling machanisms can be effective at any given point in time.

If an error handling procedure was invoked through the $ETRAP method, and the value of $ECODE is non-empty when QUITing from the level of which the error occurred, the behavior is to transfer control to the error handler associated with the newly unstacked level. However, if the QUIT command at the end of error level happens to unstack a saved value of $ZTRAP (and thus cause the value of $ETRAP to become empty), the error handling mechanism switches from $ETRAP-based to $ZTRAP-based.