Not at all. I think it is inappropriate for anyone other than the Kernel to make logic decision on the severity of the particular error. You could have a junior programmer who sees a <DISKFULL> error and is not familiar with that error so they ignore it or treat it with the same concern as an <UNDEF> X variable.
In your example, what should the average programmer do if they detect a M13 error in their error trap? Should they continue processing? Should they absolutely HALT? Should they do something in between? The answer is clear which is it depends on what <tag>^routine is non-existent. If FILE^DIE is non-existent I better shut all access off to the system until I resolve the problem. If I am not mistaken, there is no way in a M-implementation independent way to determine this. If the M system is M95 compliant it should have the $ECODE. But I believe that the text assoicated with the $ECODE is M-implementation dependent.which would help determine the severity of the error. With an organization as large as the VA, you must have error processing being done is a uniform and consistent manor independent of the level of expertise of the individual developer. I believe the reason the VA has not yet developed a "standard" error handling API is this dependence upon the M implementation. Also, when is an <UNDEF> or <NON-EXISTENT LINE LABEL> error critical or not? Determining the severity of an error is far from a trivial task. Even as good as the DSM developers were, they had bugs directly related to this issue of when to stop or not stop processing. Years ago I was performing an integrity checker on a disk and told it to fix bad blocks if it could. That disk must have been hosed to begin with. The integrity checker ignored all error messages including <DISKFULL>. It started writing new blocks to any old arbitrary block whether it was in use or not once the disk filled up. The only way I knew this happened was that the system eventually crashed when disk had gotten so corrupted with these random writes to any block. Do you really want the average programmer to make decisions as to what to do or not within their own user defined error trap? I think not. I can see one exception to this, possibly. You set the error trap and look for a specific error message. All other messages are treated as fatal and sent to the Kernel. Prior to the %ZISH utilities, you had to do this on a DSM system. The only way to tell you were at the end of a file was to examine $ZE["ENDOFILE". This example is not valid now since we have the %ZISH utilities. ----- Original Message ----- From: "Greg Woodhouse" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, April 04, 2005 6:48 PM Subject: Re: [Hardhats-members] Maintaining database integrity > > --- steven mcphelan <[EMAIL PROTECTED]> wrote: > > > There is no way in Hades I would support this unless it was done > > properly. > > Are you suggesting that I'm saying it should be done improperly? > > Two techniques that I believe could be used to advantage are sertting > $ECODE for user defined errors (often a better alternative to > circuitous code maintaining all kinds of condition variables) and > calling UNWIND^%ZTER to unwind the stack and quit back to the calling > routine (as an alternative to a "hard crash"). A simple example: > > > >ZL ZZGREG6 ZP > ZZGREG6 ; ; 4/4/05 6:45pm > EN2 ; > N I > F I=1:1:10 D > .D OUCH(I) > .W !,"I = ",I > W !!,"DONE!" > Q > ; > OUCH(J) ; > N $ETRAP,$ESTACK S $ETRAP="D ERR^ZZGREG6" > D:J=5 NOPE^ZZGREG6 > Q > ERR ; > N MYEC > S MYEC=$$EC^%ZOSV > W !!,MYEC > D UNWIND^%ZTER > Q > > >D ^ZZGREG6 > > I = 1 > I = 2 > I = 3 > I = 4 > > OUCH+2^ZZGREG6:1, %DSM-E-LINER, Undefined line label, -DSM-I-ECODE, > MUMPS error > code: M13 > I = 5 > I = 6 > I = 7 > I = 8 > I = 9 > I = 10 > > DONE! > > > > Of course NOPE^ZZGREG6 doesn't exit. Ther whole point is to force an error. > > A practical man is a man who practices the errors of his forefathers. --Benjamin Disraeli > ==== > Greg Woodhouse > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
