[1.3b56-70] Try() function to suppress error messages?

[biodude]

Error messages can be useful for debugging, but a pain to try to avoid at times. I would like to request a function that can attempt to execute code, and returns a logical to indicate whether the code generated any error messages. This would be similar to evalMacro, except that error messages would be suppressed (or returned as a string instead of being output to chat?).
e.g.

Code: Select all

[H: string = "-" ]
[H: fail = try( "[ value = eval( string ) ]" )]

Alternatively, something similar that returns an empty string instead of generating an error message, otherwise the result of the code as evalMacro (or execMacro). Or, an optional argument could change different behaviours (new variable scope, what is returned, etc.)

Reason: Some functions are quite finnicky about the arguments passed to it, and there are times when I don't really care what the error is, I just want to know if the code can execute without errors e.g. comparison of values (of different types), and the [wfunc]eval[/wfunc] function in particular.

[aliasmask]

Having a try/ catch overload would be awesome.

Things that I don't like:

• String && JSON comparison in if tosses an error.
• Too many ()'s in if
• Using macro.args when not defined

It may be useful to have a constant names NULL to represent NULL data so we can use for comparison. Currently, I just use [wfunc]json.isEmpty[/wfunc] but that really requires two or more checks just in case Empty string is valid, but NULL is not. If's break when trying to compare Null data.

[Azhrei]

I seriously doubt that anything of this scope will be added to 1.3. And Javascript does have exceptions built-in so I expect you'll have to wait for JS.

[Imper1um]

Could you at least tell me where this error:

"Invalid number of parameters 2, expected exactly 3 parameter(s)"

occurred? This tells me nothing except that "something broke." Unfortunately, when an error like this comes up, output is suppressed, so I can't even have Debug Information. Now, I got to edit my macro which references 30 other macros, unwinding it until I find the culprit.

[aliasmask]

What I've done in the past, especially when I have a long chain of macros is put a debug line at the top of all my macros. The debug will post a dialog with the dialog the same name as the macro name along with the macro.args.

Code: Select all

@@debug
[H, if(0), code: {
   [H: title = json.get(macro.args,0)]
   [H, if(isDialogVisible(title)): closeDialog(title)]
   [dialog(title,"temporary=1;"):{[macro.args]}]
};{}]

<!-- Example call to debug -->
[H: am.sp.debug("setTableField",macro.args)]
 

I'm sure you can get more fancy with settings and output, but this will get the job done. Since the most recent dialog is on top, you get an idea of the order of execution as well. Debug is a UDF, so you'll have to set that up as well. I use if(0) or if(1) to turn it on or off.

This should at least tell you which macro the problem is in then you can use aborts to see which line has the error if it's not obvious from there.

[Azhrei]

Now, I got to edit my macro which references 30 other macros, unwinding it until I find the culprit.

Yep, it's a bummer. But the answer is "not easily" due to the way the input functions interact with the parser.

alias's solution is a good one, especially if you add a global flag that can turn them all on/off at once.

[Imper1um]

Now, I got to edit my macro which references 30 other macros, unwinding it until I find the culprit.

Yep, it's a bummer. But the answer is "not easily" due to the way the input functions interact with the parser.

alias's solution is a good one, especially if you add a global flag that can turn them all on/off at once.

So you can't find out what the last Macro ran was?

[biodude]

FYI

Error messages can be suppressed in User-Defined Functions, by defining a function with "output suppressed" (see [wfunc]defineFunction[/wfunc]). This generally causes a function to return an empty string, rather than an error message. However, this is only true if the option for "Use ToolTips for Inline Rolls" is turned off in the MapTool preferences. If this is turned on, error messages are generated as normal.

Does anyone know the reason for this difference in behaviour? Is it a bug, or is there a deliberate reason for the difference that I'm missing? It makes sense that it would be related to output being suppressed, but I don't quite understand why the tooltip option would alter this behaviour so drastically (other than the way it affects macro output?).

[Azhrei]

So you can't find out what the last Macro ran was?

No, not without a massive kludge.

[aliasmask]

I working on RPDebugger where it will give you a bunch of information including the last macro before the error. Currently, I have a "pre release" version out but version 1 should be posted sometime soon (tomorrow). I'm just debugging the debugger and formatting the output.