LabVIEW
How to throw an exception from DLL generated from LabVIEW
LabVIEW does not have a way to generate exceptions. There were some ideas about how to replace the omnipresent error cluster by something more akin to exceptions, but it never went anywhere and even if it would exist it would not be the type of exceptions that a C++ library generates. There are additional difficulties with this since there were traditionally several very vigorously defended (and through patents protected) ways of implementing exceptions. The Borland way was very different to the Microsoft way partly because none of the two sides would want to let the other use its method. I'm not clear on what the current patent situation is in respect to exception handling, but even if that is not an issue anymore, I'm quite certain that libraries generated in g++ are not automatically exception handling compatible with libraries generated in MSC. That is probably not a big concern since those libraries are generally not binary compatible anyhow. So aside from implementing exception handling in a way that your Python library could properly catch them, there is the additional difficulty that it would only work if your Python interface was compiled with the same C++ compiler as the library you want to catch exceptions from.
The only universally compatible way to do error handling is by returning an error status explicitly to the caller and checking it there. Everything else is bound to cause problems since C(++) compilers do tend to do many things according to the standard, which is often: This behaviour is implementation specific!
If you would go .Net things are possibly more straightforward. The .Net framework specifies how exceptions are meant to be passed up the call chain. Still there is no native LabVIEW throw primitive so simply generating a .Net assembly from the LabVIEW code buys you nothing. There might be a way to generate exceptions anyhow through some kind of involved .Net reflection invocation, but honestly I would judge this as something not worth the trouble and potential pitfalls.
