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
