Exception Handling in JMP 11

[#1]

Hi,

Is it possible to use try()/throw() to look for specific JMP exceptions?

I have a scheduler that updates several tables from several dynamic sources.

I would like to catch things like missing files, columns, or incorrect data types and write them to a log.txt so that it's easy for me to look for and fix anything if the scheduler crashes. Similar to try and catch in java.

I know the function log capture() exists, however because I'm using try() the error doesn't get a chance to be written to the log. It just jumps to my catch expressions.

I can post up sample code if needed.

Thanks!

[#2 · Accepted solution]

The only way to get feedback in the catch expression of a JSL try() function is through the Exception_msg variable, but that variable is not always set to a useful value.  Sometimes it is.  You can use the JSL throw() function to set it, like this:

try( print("hello"); throw("bang!"), show(exception_msg))

"hello"

exception_msg = "bang!";

So you could wrap other JSL that might create an exception with something like this:

myOpen = function({file},

  try(open(file),

    throw("could not open "||file|| " details="||char(exception_msg)))

);

try( myopen("NOSUCHFILE.JMP"), show(exception_msg) );

exception_msg = "could not open NOSUCHFILE.JMP details=.";

Open didn't set the exception_msg (no details, above), but sqrt(string value) does (extra details, below):

mysqrt = function({v},

try(sqrt(v),

  throw("could not sqrt "||v|| "\!ndetails="||char(exception_msg)))

);

try( mysqrt("minus one"), write(exception_msg) );

could not sqrt minus one

details={"Cannot convert argument to a number [or matrix]"(1, "Sqrt", Sqrt /*###*/(v))}

So you don't really need a wrapper for sqrt.  By concatenating the possible exception_msg to your own, more illuminating message, you'll get more details if open is enhanced to return the exception message in the future.  The char() function around the exception_msg converts a non-existent message to a valid string for concatenation.

[#3]

Thanks Craig, that's pretty much the method we had implemented as a stand by. We had forced our interfaces to use our own exception message variable using wrappers to trouble shoot problems. You were able to shed some light on why some of the outputs from JMP's exception_msg variable was lacking in any information.

Is there any documentation of all possible outputs of the exception_msg variable,  and the exceptions that trigger them?

I could see this being extremely useful in planning.

[#4]

Investigated further.  The JSL try( ) function (and LogCapture) really could do a better job; it is overlooking several kinds of messages it could report back through the exception_msg.  The end result is try( ) catches the error, but the exact error message is suppressed (and not sent to the log either).

I'm pretty sure there won't be a list of exception_msg possibilities.  Sometimes the exception_msg will be a string and sometimes it will be a list (as seen in two previous examples).

Thanks, I'll add this to my list - Craige