You make a good argument here, and certainly avoiding the kinds of
problems you describe is one reason I'd like to standardize error
handling in VistA. And incidentally, user specified error traps are
certainly not forbidden today. We're not talking about opening up an
option to programmers that didn't exist before. Unfortunately, though,
we can't have it both ways: if code is to be modular there must be a
mechanism through which those modules communicate. If you ever set up a
callback you should probably b prepared to respond intelligently to a
M13 error. How to prevent programmers from shooting themselves in the
foot is an interesting problem. As we all know, Java went to some
lengths to eliminate particularly error prone features of some other
languages (e.g., explicit memory de-allocation). But does that mean
that shooting one's self in the foot in Java is impossible? Of course
not! You could put try statements in a tight loop repeatedly executing
the same SQL statement via JDBC. Would that be wise? Of course not.
Would ignoring <DISKFULL> errors inside a tight loop be wise in MUMPS?
Again, the answer is that it obviously is not. In fact, isn't this just
the same problem in a different environment? Maybe we could eliminate
KILL statements via some garbage collection process (and, in fact, this
is exactly what we do with ^XTMP). We have standards saying data should
be stored in Fileman compatible globals and data stored in ^TMP
requires $J as a subscript in the first or second position. In other
words, there is a lot that can be done to promote safety, but these
requirements are not free and they do not make SAC compliant code
bulletproof. Obviously that cannot be done (unless the halting problem
is solvable after all!)
====
Gregory Woodhouse
[EMAIL PROTECTED]
On Apr 4, 2005, at 7:16 PM, steven mcphelan 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
-------------------------------------------------------
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
