Comment vraiment piéger toutes les erreurs avec $ etrap dans Intersystems Caché?

Question

Je me suis souvent cogné la tête à cause de ça. De la façon dont $ etrap (erreur traitant la variable spéciale) a été conçu, vous devez faire attention à vraiment piéger toutes les erreurs. J'ai partiellement réussi à le faire. Mais il me manque toujours quelque chose, car lorsqu'il est exécuté en mode utilisateur (mode application), il y a erreurs de bibliothèque de cache interne qui sont toujours en cours d'arrêt de l'application.

Ce que je ne faisais que:

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 

Après tout cela, je vois que quand je l'appelle le programme à partir d'une invite cela fonctionne! Mais quand j'appelle de Cache Terminal Script (mode d'application, on m'a dit) il échoue et annule le programme (le mécanisme de piégeage d'erreur ne fonctionne pas comme prévu).

Des lumières?

Merci à l'avance,

Luís Fernando

Answer 1

Est-il possible qu'un piège d'erreur de style ancien (ZTRAP $) est mis en oeuvre que Usermode?

La documentation sur ce sujet est assez bonne, donc je ne vais pas tout répéter ici, mais un point clé est que $ ZTRAP n'est pas New-ed de la même manière que $ ETRAP. D'une certaine manière, il est "implicitement nouveau", en ce sens que sa valeur ne s'applique qu'au niveau de la pile en cours et aux appels suivants. Il retourne à n'importe quelle valeur précédente une fois que vous avez quitté le niveau dans lequel il a été défini.

De même, je ne suis pas sûr s'il existe un ordre de priorité défini entre les gestionnaires $ ETRAP et $ ZTRAP, mais si $ ZTRAP est de priorité plus élevée, qui remplacerait vos $ ETRAPs.

Vous pouvez essayer de régler $ ZTRAP vous-même avant d'appeler la fonction de bibliothèque. Réglez-le sur quelque chose de différent de $ ETRAP pour être sûr de savoir lequel a été déclenché.

Même cela pourrait ne pas aider cependant. Si $ ZTRAP est défini dans la fonction de bibliothèque, la nouvelle valeur sera effective, donc cela ne fera pas de différence. Cela ne ferait que vous aider si la valeur de $ ZTRAP venait de quelque part plus haut dans la pile.

Vous n'avez pas mentionné quelle fonction de bibliothèque a causé cela. Mon entreprise a un code source pour certaines fonctions de la bibliothèque, donc si vous pouvez me dire le nom de la fonction, je vais voir ce que je peux trouver. Merci de me donner la valeur de $ ZVersion aussi, donc je peux être sûr que nous parlons de la même version de Cache.