I'm not an expert in error handling in any language.
But the default in the other languages is that the
error won't be trapped by a child unless they
specifically ask to handle it. The presumption is
that a child won't ask to handle an error (such as
DISKFULL) unless they know how to do it. For example,
I wouldn't even know that a DISKFULL error existed, so
I obviously wouldn't set up a handler for that
particular error.
You said that M *can* do this, but what is the default
behavior?
For example, I set an error trap in one of my
functions. Am I now responsible for all errors that
fall into it? Here is my code
. if $data(TMGFDA)'=0 do
. . new $etrap set $etrap="do ErrTrp^TMGDBAPI"
. . set ^TMP("TMG",$J,"ErrorTrap")=result
. . set ^TMP("TMG",$J,"Caller")="UPDATE^DIE"
. . do UPDATE^DIE(Flags,"TMGFDA","RecNum","TMGMsg")
. . set result=^TMP("TMG",$J,"ErrorTrap")
. . kill ^TMP("TMG",$J,"ErrorTrap")
. . kill ^TMP("TMG",$J,"Caller")
And here is my error trap
ErrTrp
new cAbort set cAbort=0
set $etrap="",$ecode=""
new Caller
set Caller=$get(^TMP("TMG",$J,"Caller"),"?")
do ShowError^TMGDEBUG(.PriorErrorFound,"Error
trapped. Caller was: ",Caller)
if $data(TMGMsg) do ShowDIERR^TMGDEBUG(TMGMsg)
set ^TMP("TMG",$J,"ErrorTrap")=cAbort
quit
Would this ignore a DISKFULL error?
Kevin
--- Maury Pepper <[EMAIL PROTECTED]> wrote:
> 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: <hardhats-members@lists.sourceforge.net>
> 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: <hardhats-members@lists.sourceforge.net>
> >> 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
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Yahoo! Personals - Better first dates. More second dates.
http://personals.yahoo.com
-------------------------------------------------------
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
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
