I mentioned earlier that this was part of a debugger package. As my
debugger allows for stepping the code, I added a command-line function
named SHOW. It essentially dumps out a variable that the user inputs.
Then I, being a bad user, somehow entered in an arugument to SHOW
that included a null
What does your application do when it does encounter a null subscript? I think that is the more important problem than a M error thrown when it happens. In production software, why would your application encounter a null subscript in the first place? Usually it is the resultof bad data or missing
--- Steven McPhelan [EMAIL PROTECTED] wrote:
What does your application do when it does encounter a null
subscript? I
think that is the more important problem than a M error thrown when
it
happens. In production software, why would your application
encounter a
null subscript in the first
@lists.sourceforge.net
Subject: Re: [Hardhats-members] Protecting against indirection errors.
--- Steven McPhelan [EMAIL PROTECTED] wrote:
What does your application do when it does encounter a null
subscript? I
think that is the more important problem than a M error thrown when
it
happens
--- Cameron Schlehuber [EMAIL PROTECTED] wrote:
So, Greg, do you ALWAYS use the $GET and then on top of that, check
for
$LENGTH before using such values as subscripts? Etc. etc.
Pretty much...except, I tend to use $GET inside $PIECE like so
S
, March 01, 2006 9:33 AM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] Protecting against indirection errors.
--- Steven McPhelan [EMAIL PROTECTED] wrote:
What does your application do when it does encounter a null
subscript? I
think that is the more important problem
--- [EMAIL PROTECTED] wrote:
By the way, I have used the let it crash technique to seal up holes
in
already existing applications so I could trace back how bad data got
into the system via which modules and applications
Does everyone realize that you can still log an error after you
Yep, I like it so much that I created a package to track the history of
specific errors that come from specific routines. This is really valuable
to see when a specific problem first started and who was involved. It may
be a software bug, or a training issue (especially if only a single user
is
I understand all this. I also made some assumptions in my statements. I had assumed that a process was initiated either through an RPC Broker connection or invoking an OPTION from Menuman through proper Kernel sign-on. In both of these cases, the Kernel sets an initial error trap for that process.
:
Steven McPhelan
To: hardhats-members@lists.sourceforge.net
Sent: Wednesday, March 01, 2006 2:39
PM
Subject: Re: [Hardhats-members]
Protecting against indirection errors.
I understand all this. I also made some assumptions in my
statements. I had assumed that a process
--- James Gray [EMAIL PROTECTED] wrote:
I cannot tell for sure because none of the rest of the thread is
attached, but I believe this thread was started by Kevin who was
working on an application that did not meet either of your
assumptions. It was a programmers debugging tool.
Jim Gray
Kevin wrote:
Well, I had hope the ^DIM would work for me. Unfortunately it imposes
SAC (SAAC? SACC?) restrictions. It I try this
set X=SET TEMP=$GET(k) do ^DIM
X will be deleted. I assume this is because lowercase variables are
not allowed.
My debugger is not designed to be VA specific, so
Wow! Did you write that special for me? I'll check this code out!
Dave Whitten called and pointed out that I could do this, also:
set X=$UP^XLFSTR(SET TEMP=$GET(_myref_)) do ^DIM
By forcing uppercase, I am changing the actual variable examined. But
it will still catch null nodes etc.
--- Kevin Toppenberg [EMAIL PROTECTED] wrote:
Dave Whitten called and pointed out that I could do this, also:
set X=$UP^XLFSTR(SET TEMP=$GET(_myref_)) do ^DIM
I can't believe I didn't think of that! Of course, everything is
obvious after the fact.
BTW, Have you ever just read through
Kevin wrote:
Wow! Did you write that special for me? I'll check this code out!
Yes, and to see what further discussion might come of it. It is not complete,
but I think
it will fit most of the need you described for interactive syntax checking in a
debugger.
I have been thinking that I would
Well, I had hope the ^DIM would work for me. Unfortunately it imposes
SAC (SAAC? SACC?) restrictions. It I try this
set X=SET TEMP=$GET(k) do ^DIM
X will be deleted. I assume this is because lowercase variables are
not allowed.
My debugger is not designed to be VA specific, so allow a user to
@lists.sourceforge.net
Subject: Re: [Hardhats-members] Protecting against indirection errors.
Well, I had hope the ^DIM would work for me. Unfortunately it imposes
SAC (SAAC? SACC?) restrictions. It I try this
set X=SET TEMP=$GET(k) do ^DIM
X will be deleted. I assume this is because lowercase
On Sat, 2006-02-11 at 23:07 -0600, Kevin Toppenberg wrote:
[KSB] ...snip...
The main problem I have run into is when one of the nodes is null,
with GT.M doesn't allow in VistA (I think it is possible to configure
it to allow this!). Isn't there a command to list out the various
nodes in
You could try using
DO ^DIM
You would have to have
Set X=Set RESULT=$Get(_PREF_)
to get ^DIM to evaluate the string properly. Does this make sense?
Jim
- Original Message -
From: Kevin Toppenberg [EMAIL PROTECTED]
To: Hardhats Sourceforge hardhats-members@lists.sourceforge.net
Kevin,
What do you want to happen when the error is detected?
Your third example would give a syntax error. I would expect this to be a
programming
error. In my work, it seems that the standard error response of logging the
error and
halting (or dropping back to the MUMPS shell) is generally
Interesting. I'll check it out.
On 2/11/06, James Gray [EMAIL PROTECTED] wrote:
You could try using
DO ^DIM
You would have to have
Set X=Set RESULT=$Get(_PREF_)
to get ^DIM to evaluate the string properly. Does this make sense?
Jim
See below
On 2/11/06, Jim Self [EMAIL PROTECTED] wrote:
Kevin,
What do you want to happen when the error is detected?
I would want the function to have a chance to return a 'failure' value.
Your third example would give a syntax error. I would expect this to be a
programming
error.
Not
On calling ^DIM, while it would protect most types of errors if used
properly (unless the indirected statement had indirection in it ;-),
would be really slow for any significant volume of calls. It is a MUMPS
syntax parser written in MUMPS.
This is the danger of dynamic, late binding unless
On Feb 11, 2006, at 4:59 PM, Greg Kreis wrote:
This is the danger of dynamic, late binding unless you want to go
to compile or on-the-fly compiling. But hey, along with the danger
comes the great flexibility. Do you want to have your cake and eat
it to? ;-) ;-)
You can, but it
You could validate the string to make sure it is a valid global reference.
I'm sure there is a clever pattern match that would serve for most cases.
If you want to handle variables in the string like ^VA(200,DUZ,0) you
might need a loop.
The error trap is faster to build, easier to prove correct
On 2/11/06, Gary Monger [EMAIL PROTECTED] wrote:
You could validate the string to make sure it is a valid global reference.
I'm sure there is a clever pattern match that would serve for most cases.
If you want to handle variables in the string like ^VA(200,DUZ,0) you
might need a loop.
The
: Re: [Hardhats-members] Protecting against indirection errors.
On 2/11/06, Gary Monger [EMAIL PROTECTED] wrote:
You could validate the string to make sure it is a valid global reference.
I'm sure there is a clever pattern match that would serve for most cases.
If you want to handle variables
: [Hardhats-members] Protecting against indirection errors.
On 2/11/06, Gary Monger [EMAIL PROTECTED] wrote:
You could validate the string to make sure it is a valid global reference.
I'm sure there is a clever pattern match that would serve for most cases.
If you want to handle variables
-members] Protecting against indirection errors.
On 2/11/06, Gary Monger [EMAIL PROTECTED] wrote:
You could validate the string to make sure it is a valid global reference.
I'm sure there is a clever pattern match that would serve for most cases.
If you want to handle variables in the string
]
[mailto:[EMAIL PROTECTED] On Behalf Of Kevin
Toppenberg
Sent: Sunday, February 12, 2006 12:08 AM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] Protecting against indirection errors.
On 2/11/06, Gary Monger [EMAIL PROTECTED] wrote:
You could validate
Kevin wrote:
On 2/11/06, Jim Self [EMAIL PROTECTED] wrote:
Kevin,
What do you want to happen when the error is detected?
I would want the function to have a chance to return a 'failure' value.
Your third example would give a syntax error. I would expect this to be a
programming
error.
31 matches
Mail list logo
