LabVIEW
How can I dump a call stack when there is an error?
Solved!
@iCat wrote:
"call chain" VI only prints a call stack starting from the VI that contains the call chain VI.
Since I use a SubVI that handles errors and the call chain VI can't be located in the VI where an error occurs,
"call chain" VI is not useful in an error logging VI.
In java, you have Throwable.printStackTrace() that prints the entire call stack.
Does LabVIEW have an equivalent of Throwable.printStackTrace()?
I may have gotten this wrong but if you are concerned about the fact that the Call Chain includes the name of your Error Handler VI it's very easy to delete the first element of the Call Chain array to exclude that name from the list. Otherwise please explain in a different way what you want to do.
@iCat wrote:
nathand // There is no call chain in the error cluster.
rolfk // The problem is that the first element of the array is at the deepest level of the call chain.
Let's assume that I placed "call chain" VI in D.vi
E.vi invokes D.vi(D<-E).
And the VI tree is "A<-B<-C<-D<-E".
If a VI generated an error in A.vi, "call chain" VI would only return "D.vi" and "E.vi" in the returned array.
I want to see "A.vi", "B.vi", "C.vi", "D.vi", and "E.vi" in the call chain array.
But it's impossible to place "call chain" VI at the lowest level(A.vi in this case) for a large web of VIs.
A.vi could be placed at the second lowest level later in time.
WEll you may have to rethink what you expect here. You want to have the same as Structured Exception Handling but besides that there are actually patents on several of those implementations, LabVIEW works a little different since it's all about dataflow. Basically what I do in LabVIEW is to have a VI that is placed where an error could occur. It checks for the error condition and if met adds the actual call stack (Call Chain - the number of levels the error checker uses) plus extra error information into the error cluster. Basically it is what in other languages is the throw statement. All consecutive VIs have this error cluster usually wired through and don't do anything (except the close function which does attempt to close any resources anyhow) if there is an error in. Then at the end of your operation, usually in a higher level VI there is an error handler, that logs the information, shows a dialog or does whatever else makes sense for an error in that context. So your call stack is determined at the point where the error happens but you do not have to code that each time, as you can write a subVI that you can drop into the diagram to handle that for you and add the information to the error cluster.
The error cluster is not exactly the most ideal way to handle structured exception handling but it is a mechanisme that was introduced long ago, and has worked fairly well, or at least not bad enough that many people have worried about trying to find a more universal (and still easy to handle) mechanisme.
Absolutely! and I tried to explain it in my last post. But ok, since pictures say sometimes more than 1000 words here you go.
The right side is a function that checks to see if the file exists and if it does attempts to open it in the external viewer that is registered on the computer for this file type. If it doesn't (which is shown here) it generates an error message and puts it in the erorr cluster. The diagram for the VI generating the Call chain is shown on the left. Skip level is used if the actual Call Chain VI might be buried deeper in the hierarchy of error helper VIs to exclude their names which would add no extra information.
For instance building the error cluster could be also put in a subVI if you happen to have that often for instance with API Calls that only return an error code. In that case I have usually a library specific Build Error VI, that receives the error number (usually 0 means success and non-zero is the error code), and creates the Call Chain and then puts that and the error code in the error cluster. It could also incorporate a call to an API to add error specific text information to the error message, if that API supports that.
