Programmatically breaking execution

[mje]

I'm in the process of designing a debugging library...still at the stage of throwing ideas around.

One thing that I can't decide how best to implement is an assertion VI. The behavior I'd like is that if an assertion fails, I'd like LV to break execution and highlight the call to the VI on the diagram of whatever called it (kind of similar to the automatic error handling bit LV does). One way to do it would be to have an error output I suppose, that by convention shouldn't be wired, but that relies on the calling VI to have error handling enabled. Is there a way to programmatically suspend execution and highlight the VI call?

-michael

[Yair]

QUOTE (MJE @ Nov 23 2008, 03:40 PM)

Is there a way to programmatically suspend execution and highlight the VI call?

There might be some scripting methods for this, although I don't remember any off hand (which doesn't mean they don't exist).

Personally, I like auto error handling and I think it's a good tool for catching errors you forgot to handle, so having your assertion VI have an extra error output sounds like a reasonable method, but auto error handling isn't always guaranteed to work.

Another method you can try is placing a breakpoint inside a case structure in your assertion VI. Then, whenever you want to trigger the assert, simply call the case with the BP in it. One problem is that if the BP will be inside the assertion VI, you won't see where the actual error came from, but there are at least two options for this:

1. Use the source element of the error cluster.

2. When a BP pauses a VI, the font ring should change to show you the calling hierarchy and you can use that to get to the caller.

P.S. If you don't mind doing it manually, you can also simply use a conditional probe, but you will lose its placement every time you close the BD.

[Tim_S]

QUOTE

Another method you can try is placing a breakpoint inside a case structure in your assertion VI. Then, whenever you want to trigger the assert, simply call the case with the BP in it. One problem is that if the BP will be inside the assertion VI, you won't see where the actual error came from, but there are at least two options for this:

The breakpoint could be outside of the assertion VI. The assertion VI could output an error cluster which chooses between cases. The error case could contain the breakpoint. Probing at the breakpoint would give you the current error cluster's value and possibly information as to why the assertion is throwing up a red flag.

Tim

[mje]

Putting the breakpoint in the assertion VI will work, but as Yair pointed out, will cause execution to halt in the VI, when I'm more interested in halting within the calling VI and highlight the call to the assertion so the offending code can be seen.

I'm still undecided if I even want to use such a VI, I'm trying to design it only for consistency with traditional debugging tools, and historically I'm against debugging assertions at all: if a condition is important enough that it warrants an assertion, use a full error test and breakpoints as needed. However I realize that it's really a design philosophy and some people like them.