Combining GetRTError(1) and AbortOnRTE
thomas_braun
Hi igoristas,
I have some code which tries to talk to hardware
debugOnError = DisableDebugOnError()
try
MCC_SelectMultiClamp700B(mccSerial, channel); AbortOnRTE
catch
errorCode = GetRTError(1)
ResetDebugOnError(debugOnError)
return AMPLIFIER_CONNECTION_MCC_FAILED
endtry
try
MCC_SelectMultiClamp700B(mccSerial, channel); AbortOnRTE
catch
errorCode = GetRTError(1)
ResetDebugOnError(debugOnError)
return AMPLIFIER_CONNECTION_MCC_FAILED
endtry
and as that might not always work I'm handling the error case myself.
Now I would like to get rid of the necessary debugOnError disabling/resetting. According to documentation I can use getRTError(1) on the same line as the command to get rid of the debugger fiddling logic (IP7 and above).
I've tried with this example
Function IAbort()
Make/FREE/N=0 data
data[0] = NaN
End
Function Dostuff()
variable errorCode
try
IAbort(); errorCode = GetRTError(1); AbortOnRTE
catch
print "error"
endtry
End
Make/FREE/N=0 data
data[0] = NaN
End
Function Dostuff()
variable errorCode
try
IAbort(); errorCode = GetRTError(1); AbortOnRTE
catch
print "error"
endtry
End
but could not get it working as the debugger either still opens or I'm not landing in the catch block.
Any ideas what I'm doing wrong?
Since the error is in IAbort(), not DoStuff(), DebugOnError is opening the debugger at the data[0]=NaN line.
If you'd had
Make/FREE/N=0 data
data[0] = NaN; Variable errorCode=GetRTError(1)
return errorCode
End
then the debugger would not open. But the try/catch in DoStuff() would be pointless since the called routine cleared the error.
I think you're stuck disabling DebugOnError (which was designed to be used only in a development environment) if you are deploying this code to a production environment with DebugOnError turned on.
August 1, 2018 at 01:39 pm - Permalink
Thanks for the explanation Jim.
August 2, 2018 at 06:35 am - Permalink
I'm coming back to this issue as I have more and more code which uses try/catch and AbortOnRTE.
For example one of the functions fetches the latest value from a thread queue
///
/// Return `NaN` if the thread is not running anymore.
///
/// Throws away anything else in the datafolder from the thread queue.
Function TS_GetNewestFromThreadQueue(tgID, varName)
variable tgID
string varName
variable var = NaN
variable err
ASSERT_TS(!isEmpty(varName), "varName must not be empty")
if(IsNaN(tgID))
return NaN
endif
for(;;)
try
ClearRTError()
DFREF dfr = ThreadGroupGetDFR(tgID, TS_GET_REPEAT_TIMEOUT_IN_MS); AbortOnRTE
catch
err = GetRTError(1)
return NaN
endtry
if(!DataFolderRefStatus(dfr))
if(IsFinite(var))
return var
elseif(TS_ThreadGroupFinished(tgID))
return NaN
else
continue
endif
endif
NVAR/Z/SDFR=dfr var_thread = $varName
ASSERT_TS(NVAR_Exists(var_thread), "Expected variable from thread does not exist: " + varName)
// overwrite old values
var = var_thread
endfor
return var
End
And now if I have to debug a problem in the application in unrelated code using DebugOnError, the debugger pops occasionally up on the AbortOnRTE line. This is never a problem as I anticipated that already in this piece of code.
So this makes using DebugOnError a bit annoying.
From my limited Igor Pro understanding I would say that a line with trailing AbortOnRTE should have DebugOnError implicitly disabled for this line only. The whole point of AbortONRTE is that a RTE is expected and the code is designed to handle that.
Thanks for considering,
Thomas
March 1, 2019 at 05:28 am - Permalink