因此，我一直在been头。在设想$ etrap(错误处理特殊变量)的方式中，您必须小心地真正捕获所有错误。我已经在此方面取得了部分成功。但是我仍然缺少一些东西，因为在用户模式(应用程序模式)下运行时，仍然存在内部缓存库错误，这些错误仍在暂停应用程序。
我所做的是:
ProcessX(var)
set sc=$$ProcessXProtected(var)
w !,"after routine call"
quit sc
ProcessXProtected(var)
new $etrap
;This stops Cache from processing the error before this context. Code
; will resume at the line [w !,"after routine call"] above
set $etrap="set $ECODE = """" quit:$quit 0 quit"
set sc=1
set sc=$$ProcessHelper(var)
quit sc
ProcessHelper(var)
new $etrap
; this code tells Cache to keep unwindind error handling context up
; to the previous error handling.
set $etrap="quit:$quit 0 quit"
do AnyStuff^Anyplace(var)
quit 1
AnyStuffFoo(var)
; Call anything, which might in turn call many sub routines
; The important point is that we don't know how many contexts
; will be created from now on. So we must trap all errors, in any
; case.
;Call internal Cache library
quit
完成所有这些之后，我可以看到，当我从提示符下调用该程序时，它可以工作!但是，当我从Cache Terminal Script(应用程序模式，被告知)调用时，它失败并中止程序(错误捕获机制无法按预期工作)。
最佳答案
是否可能仅在Usermode中设置了旧式错误陷阱($ ZTRAP)？
关于此的文档非常好，因此在这里我不再重复，但是关键是$ ZTRAP不是与$ ETRAP相同的新版本。从某种意义上说，它是“隐式更新的”，因为它的值仅适用于当前堆栈级别和后续调用。退出设置级别后，它将恢复为以前的任何值。
另外，我不确定$ ETRAP和$ ZTRAP处理程序之间是否存在定义的优先级顺序，但是如果$ ZTRAP具有更高的优先级，则它将覆盖您的$ ETRAPs。
您可以尝试在调用库函数之前自行设置$ ZTRAP。将其设置为与$ ETRAP不同的名称，以便可以确定触发了哪一个。
即使那样可能也无济于事。如果在库函数中设置了$ ZTRAP，则新值将生效，因此不会有所不同。仅当$ ZTRAP的值来自堆栈上方的某个位置时，这才对您有帮助。
您没有提到是什么库函数引起的。我公司有一些库函数的源代码，因此，如果您能告诉我函数名，我将看到可以找到的内容。也请给我$ ZVersion的值，以便可以确定我们正在谈论的是相同版本的Cache。