1

因为这个，我一直在敲我的头。在构思 $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

毕竟，我可以看到当我从提示符调用程序时它可以工作！但是当我从缓存终端脚本（应用程序模式，我被告知）调用时，它失败并中止程序（错误捕获机制无法按预期工作）。

4

1 回答 1

1

是否可能仅在用户模式下设置了旧式错误陷阱 ($ZTRAP)？

这方面的文档非常好，所以我不会在这里全部重复，但关键是 $ZTRAP 不像 $ETRAP 那样是 New-ed。在某种程度上，它是“隐式更新的”，因为它的值仅适用于当前堆栈级别和后续调用。一旦您退出设置的级别，它就会恢复到任何先前的值。

此外，我不确定 $ETRAP 和 $ZTRAP 处理程序之间是否定义了优先顺序，但如果 $ZTRAP 具有更高的优先级，那将覆盖您的 $ETRAP。

您可以在调用库函数之前尝试自己设置 $ZTRAP。将其设置为不同于 $ETRAP 的值，这样您就可以确定触发了哪个。

即使这样也可能无济于事。如果在库函数中设置了 $ZTRAP，则新值将生效，因此这不会产生影响。这只会在 $ZTRAP 的值来自堆栈中的某个位置时对您有所帮助。

你没有提到是什么库函数导致了这个。我的公司有一些库函数的源代码，所以如果你能告诉我函数名，我会看看我能找到什么。请也给我 $ZVersion 的值，这样我可以确定我们谈论的是相同版本的 Cache。

于 2008-10-20T12:42:58.313 回答