Run VI From Methods Folder fails to pass errors through

[pollockm]

An error that is generated in a called method VI does not get propagated out to the client (it gets error -32603, Internal Error, but no details as to what the error actually was).

We should be taking data from the method's error line and passing it into the Add Response function.

Like this:

[tannerblair]

The expectation is that the response is built inside the template VI so specific or custom error info can be included, then the error wire is used to gate the response.

On a side note, I would be careful with when you close your VI references. It will destroy performance on repeat calls.

[pollockm]

My expectation is that if an unexpected error occurs in the processing of the command, I get an error object back. I expect this error object will contain any information that was on the error wire by default. I expect that a handled (expected) error that occurs will give me a result object with details about what happened in whatever format I specify.

I could add in the Format Error as JSON Data call to the end of every one of my method VIs, but it seems like the right place for that is in the calling framework. This simplifies all of my methods such that they only need to worry about the happy path for their response object.

If I handle the error in the method VI (such that no error comes out on the error out terminal), then yes, it should forward the response as usual in the no error case from the framework perspective. I'm referring to the case during development where I don't yet know what errors I need to handle in my methods, so I want as much information as possible piped out by default.

Not sure about the VI ref comment - you mean the Close VI Ref that was already part of the VI?

[tannerblair]

Ohhh. I haven't looked at this in a while. That whole scheme is flawed, and I need to update the template to not use that paradigm. Okay, I follow now. I agree. Here's what I typically do in my dynamic implementations:

I moved to this for two reasons:

1. The performance of loading and unloading was really terrible, and you would see a huge lag on each call.

2. It exposes a potential for code injection, because anyone can put any VI they want in there and it will run it.

So I moved to a paradigm where I load all VIs in a folder on startup, keep their refs in a variant attribute tree with the method name, then pull out the ref and call the VI when the request comes in.