I know that I need to understand this entire process,
which I currently don't. But I learn best by finding
answers for specific questions.
So in this situation, how do I say "Oops, I don't know
how to handle this, let me pass it on to someone
else"?
Thanks
Kevin
--- Greg Woodhouse <[EMAIL PROTECTED]> wrote:
> 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
>
=== message truncated ===
__________________________________
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
