Unfortunately, you are right. When you set the error trap, you define
a single handler that is invoked on ANY error. The programmer then
needs to look at $ECODE to identify the error(s) and then act
accordingly. It might be possible to emulate the Java-like model using
a library routine. In any case, I agree the Java model is better and
places a smaller burden on the programmer (always a good thing).
--- Kevin Toppenberg <[EMAIL PROTECTED]> wrote:
> 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
>
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
