environment-dependent runtime errors
tony
Is there an explanation (one that I might stand a chance of understanding?) for why bad code produces runtime errors on some systems and not others?
Specifically, I made a coding error in the baselines project:
wave w_x = $""
In testing, this line of code was executed many times without complaint, even though it should be
wave /Z w_x = $""
When I started to see runtime errors on one computer I fixed it, but the 'bad' code still runs on other machines (with same OS and Igor versions).
My guess is that the Debugger settings are different. If the debugger is enabled and "Debug On Error" is also checked you get a popup dialog.
The debugger settings can be fine tuned with DebuggerOptions.
Side note: In our testing framework, https://docs.byte-physics.de/igor-unit-testing-framework/, we treat run time errors which were generated in a test case as failure. So your "buggy" code would have led to a test failure.
October 6, 2021 at 07:21 am - Permalink
Oh, it really is as simple as that.
This particular bad code (the line in my post) generates an error with "NVAR SVAR WAVE checking" checked, but runs fine if I turn that option off, even with "Debug on Error" checked. To be honest, I hadn't even noticed that the "NVAR SVAR WAVE checking" option had been switched off, but that explains it. I thought that under rtGlobals=3 I would always generate a runtime error for this kind of thing, but that's not the case.
I just reread the help entry here
and I see that the /Z flag is really for the debugger. Now it makes sense.
October 6, 2021 at 08:53 am - Permalink
Glad this is resolved and thanks for the clarification regarding "NVAR SVAR WAVE checking".
October 6, 2021 at 08:58 am - Permalink
There are some legitimate reasons for a wave reference to be null, such as when you don't have an X wave, but need handle it if it exists. So making it an error is wrong, checking for it during debugging is very useful, and providing a way to silence the debugger if it is legitimate will save your sanity as a programmer.
October 6, 2021 at 02:39 pm - Permalink
@johnweeks: I think I don't understand your comment. Do you want to say that
wave w_x = $""
is correct code? I don't think so and would even say that it should result in an RTE. If you know that the wave can be null you can should always use /Z.
October 8, 2021 at 04:41 am - Permalink
If you actually use a null wave reference, you get a runtime error. But this:
if (WaveExists(xwave))
DoSomething(xwave)
else
DoSomethingElse()
endif
is arguably correct. But it is very annoying if you have WAVE, NVAR, SVAR checking turned on! And I agree that even without the checking, the /Z flag provides an explicit indication in the code that you *expect* that the wave reference might be null, and that is especially valuable if there is some spatial separation between the WAVE statement and the place where you check for existence.
October 8, 2021 at 12:08 pm - Permalink
In reply to @johnweeks: I think I don't… by thomas_braun
Remember that there is a lot of old Igor code out there written before WAVE/Z was invented.
Used responsibly,
WAVE w=$someStringFunctionReturningNullToSignalProblem()
can still be "correct" code.
October 8, 2021 at 05:37 pm - Permalink