我一直在敲打,因为这是我的头上了很多。在$ 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
这一切后,我可以看到,当我从一个提示调用的程序它的工作原理!但是,当我从缓存终端脚本调用(应用模式,有人告诉我)失败和中止程序(如预期的错误捕获机制不工作)。
是否有可能是一个旧式的错误陷阱($ ZTRAP)被设置只在用户模式?
这个文档是相当不错的,所以我就不再重复了所有在这里,但关键的一点是,$ ZTRAP不是新-ED以同样的方式为$ ETRAP。在某种程度上,它是“隐含新编辑”,在它的值仅适用于当前堆栈水平和后续调用。它恢复到以前的任何值,一旦你退出了过去,人们在设定的水平。
另外,我不知道是否有一个定义$ ETRAP和$ ZTRAP处理器之间的优先顺序,但如果$ ZTRAP较高优先级,这将覆盖您$ ETRAPs。
你可以尝试设置$ ZTRAP自己,你调用库函数之前权。将它设置为东西比$ ETRAP不同的,所以你可以知道哪一个被触发。
甚至可能不帮助虽然。如果$ ZTRAP被库函数内设置,新值将生效,所以这不会有所作为。这只会帮助你,如果$ ZTRAP的值从某处进一步向上堆栈来了。
你没有提什么库函数造成此。我公司有一些库函数的源代码,所以如果你能告诉我函数的名称,我会看看我能找到。请给我$ ZVersion的值太大,所以我可以肯定,我们在谈论同一版本的缓存。