How to really trap all errors with $etrap in Intersystems Caché?

Question

Hello y'all

I've been banging my head a lot because of this. In the way that $etrap (error handling special variable) was conceived you must be careful to really trap all errors. I've been partially successful in doing this. But I'm still missing something, because when run in user mode (application mode) there are internal Cache library errors that are still halting the application.

What I did was:

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

After all this, I can see that when I call the program from a prompt it works! But when I call from Cache Terminal Script (application mode, I was told) it fails and aborts the program (the error trapping mechanism doesn't work as expected).

Any lights?

Thanks in advance,

Luís Fernando

Answer 1

Is is possible that an old-style error trap ($ZTRAP) is being set only in Usermode?

The documentation on this is pretty good, so I won't repeat it all here, but a key point is that $ZTRAP isn't New-ed in the same way as $ETRAP. In a way, it is "implicitly new-ed", in that its value only applies to the current stack level and subsequent calls. It reverts to any previous value once you Quit up past the level it was set in.

Also, I'm not sure if there's a defined order of precedence between $ETRAP and $ZTRAP handlers, but if $ZTRAP is of higher precedence, that would override your $ETRAPs.

You could try setting $ZTRAP yourself right before you call the library function. Set it to something different than $ETRAP so you can be sure which one was triggered.

Even that might not help though. If $ZTRAP is being set within the library function, the new value will be in effect, so this won't make a difference. This would only help you if the value of $ZTRAP came from somewhere further up the stack.

You didn't mention what library function caused this. My company has source code for some library functions, so if you can tell me the function name I'll see what I can find. Please give me the value of $ZVersion too so I can be sure we're talking about the same version of Cache.