--- Maury Pepper <[EMAIL PROTECTED]> wrote: > M can do the same thing as what you illustrated ...
How? As far as I can tell, in MUMPS the best we can do is examine $ECODE and then base our code on that value. I guess you could do something like: N $ETRAP,$ESTACK S $ETRAP="D:$EC[""M13"" ERR^ZZGREG6" (Though, of course, you'd want a more robust test than a simple "contains".) > but, what about > the ability to prevent a child from trapping a particular type of > error? Suppose that the parent does not want the child trapping (and > perhaps ignoring or mishandling) a <DISKFUL> error? M does not > provide that and I don't know if any of the languages you sited does > either. > I need to think about this one. I believe you are right about other languages not handling this situation differently. I've thought about namespacing errors and restricting applications to trapping errors in their namespace, but I don't think the standard allows this. > > ----- Original Message ----- > From: "Kevin Toppenberg" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Tuesday, April 05, 2005 9:31 AM > Subject: Re: [Hardhats-members] Maintaining database integrity > > > > In the languages that I am familiar with, such as > > Delphi pascal, and c++, and to a degree, java, there > > is error handling that ensures that only the errors > > specifically looked for will be handled at a given > > level. For example, a programmer might have this in > > their routine: > > > > try { > > some routine that could cause an error > > } > > > > catch (EDBEngineError& E) { > > Only DBEngine errors handled here > > } > > > > catch {EMgmtError& E) { > > Only the 'MgmtError's handled here > > } > > > > But all other errors are passed to the parent > > try/catch level. > > > > Does M have this functionality? From what I am > > reading, the entire system is vulnerable to whether a > > novice programmer (like me) properly handles the > > errors that fall into his trap... i.e. they ALL fall > > in. > > > > Kevin > > > > > > --- steven mcphelan <[EMAIL PROTECTED]> wrote: > > > >> 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 > >> > > > > > > > > > > __________________________________ > > Yahoo! Messenger > > Show us what our next emoticon should look like. Join the fun. > > http://www.advision.webevents.yahoo.com/emoticontest > > > > > > ------------------------------------------------------- > > 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_ide95&alloc_id396&op=click > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > 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
