Leaderboard

This applies to windows only: I read you well. BUT!! My code can throw exceptions that are generated by NI code. Once again, I wrote the "expected answer incorrectly", because i wrote "before your code is executed" which should be any time your code is executed. The thing with CLFNs is, that if you for example attempt to execute stuff like this: int *pointer_of_doom = nullptr; *pointer_of_doom = 666; The CLFN will still report it as exception. Which is nice, since it doesn't just straight forward crash LabVIEW, when you make a pointer arithmethics error. So LabVIEW does override the signal handlers for some?! signals, and also who knows what the well documented memory manager functions may throw You write try-multicatch for all the functions you export. I just invoke them in one or more functions if needed via lambda. That's the only benefit, that you write all that try-catch stuff at just one place. Also I see you like the STD library, so beware of using the std::string or other exception capable containers in your custom exceptions, since LabVIEW overrides the terminate() handler too. You throw some exception, that is legit and has info, like if you're trying to allocate too much memory because of wrong parameters. You catch exception, string can't allocate, throws another exception in constructor, terminate() is called, and you get from LabVIEW totally non-relevant output. I had to figure this out the hard way

I typically do something along these lines. Similar to your approach, but I use the standard try-catch and an exception class derived from std::runtime_error to return my own exceptions (with error code functionality). I have a static function to return other standard errors. To make it more elegant, I could easily handle the first catch statement together with the second (downcast or string-only error). From what rolfk wrote, I could also drop the final catch, and allow the default catch mechanism of LabVIEW to handle non-standard exceptions. double foo(LVErrorCluster *lvErr, DBLArray1D** arr){ try{ return 1.0; } catch (LVException &ex) { ex.returnError(lvErr); (*arr)->dimSize = 0; return std::nan(""); } catch (std::exception &ex) { LVException::returnStdException(lvErr, ex); (*arr)->dimSize = 0; return std::nan(""); } catch (...) { LVException ex("Unknown exception has occurred"); ex.returnError(lvErr); (*arr)->dimSize = 0; return std::nan(""); } } It works well and allows me to ensure that garbage values are not read by LabVIEW. In LabVIEW, I use a merge error node with the error wire going through the call library function node. I'm a fan of generic programming and C++ templates myself, but I don't see the benefit of the exception guard, as you need to wrap the function call in a lambda expression anyway. Might as well be more explicit and use the try block.

Several remarks first: 1) You should put lv_prolog.h and lv_epilog.h includes around the error structure definition to make sure the element alignment is correct. 2) You don't show the definition of WrpExcUser exception class but if it derives from some other exception class it will catch those too. 3) Your attempt to generalize the code for catching the exception through a function pointer, so you can reuse it in multiple functions, is in principle not bad, but you loose the ability to call functions which take parameters. Not really very interesting for a bigger library. I suppose that is why you made it a template so you can replace the function pointer with specific definitions for each function but that tends to get heavy and pretty hard to maintain too. I'm not sure what your question about default error checking should mean. As far as external code goes, you as implementor define what the error checking is and how it should be performed. It's a pipe dream to have template error checking in all places the same way, reality simply doesn't work that way. Sometimes an error is fatal, sometimes it is temporary and sometimes it is even expected. Your code has to account for this on a case to case situation. As far as calling code from LabVIEW goes, unless you disable the error handling level in the Call Library Node configuration, LabVIEW will wrap the call into an exception handler of its own and return an according error in the error cluster of the Call Library Node. The reported error is not very detailed as LabVIEW has to use the most generic exception class there is in order to catch all possible exceptions but it is at least something. So generally if you don't want to do custom error handling in the external code you could leave it all to LabVIEW.

There is a whole thread on LabVIEW and SSH. and one of the posts has your solution Cat is the expert on SSH now I will however reiterate that using a username and password, although exchanged securely, is a lot less desirable than private/public keys. The later makes it impossible to brute force. There is only one real weakness with SSH - verification. When you first exchange verification hashes you have to trust that the hash you receive from the server is actually from the server you think it is. You will probably have noticed that plink asked you about that when you first connected. You probably said "yeah, I trust it" but it is important to check the signature to make sure someone didn't intercept it and send you theirs instead. Once you hit OK, you won't be asked again until you clear the trusted servers' cache so that first time is hugely important for your secrecy.

It's easy, there is probably a vi with that name in memory, so if you would remove the class prefix there would be a conflict. Rename the vi first to something unique and the try to delete it.