Is it possible to trap for a null string passed to a function? In partial answer to this, I have verified that a combination of try-catch-endtry and GetRTError(1) can do this. (Possibly GetRTError(1) alone will suffice, but I haven't tested this.) However, if the Debugger is enabled and DebugOnError is enabled, the Debugger window will still open, albeit with no error message. Is there a simple way around this situation? I have noted that a judicious use of DebuggerOptions operation can prevent this, but this seems to be a bit invasive.
My desire was to make a general purpose function as bullet proof as possible and give it the ability to gracefully exit from a null string input.
The only previous discussion to this sort of problem that I can find is here, but there was no answer.
Not that I know of. I think that wrapping all calls to the function in the try ... catch construct may be the only way. Alternatively you can check for a null string by looking for a NaN return value from strlen(). Both ways are imperfect in that they are external to the function.
jtigor wrote:
My desire was to make a general purpose function as bullet proof as possible and give it the ability to gracefully exit from a null string input.
Of course, the first question to ask is whether the function should be made robust to these kinds of conditions. Passing a null string is proof of a programmer error, and thus a bug somewhere in the code. It is not a sign of user error.
Whether this should trigger a hard or a graceful exit is, to some extent, a matter of taste. My preference in this case is to let the code blow up, especially because Igor gives us the advantage that the user does not lose any data when it does. Most situations are not like that, so under other circumstances my opinion would be different.
The reason that I prefer to do so is because I hope that it will increase the odds that I will hear about it. But opinions differ; this was discussed a while ago in http://www.igorexchange.com/node/2136
Of course, the first question to ask is whether the function should be made robust to these kinds of conditions. Passing a null string is proof of a programmer error, and thus a bug somewhere in the code. It is not a sign of user error.
I've come across this situation recently in my own code. Take the following example:
zipdecode is an XOP function for inflating a compressed string (the opposite is zipencode). A zero length string is bad input for zipdecode as even a zipencode'd zero length string has some header information.
Thus, the only correct thing to do in this situation is to return a NULL string from zipdecode (because a zero length string is a valid return from zipdecode) and create an error (wally will be NULL). Depending on the igor setup this error doesn't necessarily stop function execution.
Therefore to handle things gracefully one has to do the following, as you suggested:
One problem, and, also, maybe a blessing, is that rather than blowing up immediately on an error, the code continues to roll along even as wheels and other assorted parts fall off. You have to blow it up yourself. This means, I think, trapping for an error. If you're going to do that, then why not try to make the exit as graceful as possible? If that can't be done, then it would seem that the second best option is to try to make the post mortum informative.
I'll admit, though, that I only infrequently take this approach.
Of course, the first question to ask is whether the function should be made robust to these kinds of conditions. Passing a null string is proof of a programmer error, and thus a bug somewhere in the code. It is not a sign of user error.
Whether this should trigger a hard or a graceful exit is, to some extent, a matter of taste. My preference in this case is to let the code blow up, especially because Igor gives us the advantage that the user does not lose any data when it does. Most situations are not like that, so under other circumstances my opinion would be different.
The reason that I prefer to do so is because I hope that it will increase the odds that I will hear about it. But opinions differ; this was discussed a while ago in http://www.igorexchange.com/node/2136
July 27, 2011 at 07:04 pm - Permalink
I've come across this situation recently in my own code. Take the following example:
string wally = zipdecode(tester)
zipdecode is an XOP function for inflating a compressed string (the opposite is zipencode). A zero length string is bad input for zipdecode as even a zipencode'd zero length string has some header information.
Thus, the only correct thing to do in this situation is to return a NULL string from zipdecode (because a zero length string is a valid return from zipdecode) and create an error (wally will be NULL). Depending on the igor setup this error doesn't necessarily stop function execution.
Therefore to handle things gracefully one has to do the following, as you suggested:
abort
endif
July 28, 2011 at 01:01 am - Permalink
I'll admit, though, that I only infrequently take this approach.
July 28, 2011 at 06:08 am - Permalink