M can do the same thing as what you illustrated ... 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.
----- 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
