It's me again :)
I have another request for you. Could you add error handling to the wrappers (there are some error retminals not connected) or disable automatic error handling. The problem we are having that pop-ups appear and block the execution of the program. (it would be much better if it produced error on the wire, as we can handle this)
Best regards
Blaz
ps. sorry for three separate posts, but I thought it would be better if the issues / requests were separated into topis.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Which functions don't have error handlers connected? Every API call has its error terminals connected to Error In/Error Out in the standard convention. If not then that is an oversight that needs correcting. Unless the DVR blocks are raising error? I've never seen that before. Either way I need you to tell me which function calls are giving you problems.
The examples don't use error handling but they're just examples. Any actual application should definitely handle the Error In/Error Out terminals.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah I see. It's not actually the library call at all, but the DVR multithreading hack that errors when the input object is invalid. Arguably you should write your ZMQ code to never have invalid objects, but I also accept that the VIs should never interrupt execution at the block diagram if indeed that were to somehow occur. I would argue that if you encounter invalid objects you should rewrite your code to follow the paradigms of the guide more closely - if you can enter a state where sockets are poorly defined then data loss is probable in the worst case, and there is additional book-keeping overhead in the best case.
I just put together the v3.4.1 release where potential errors using the DVR are merged into the standard error stream. I also created two VIs (zmq_ctx_check.vi and zmq_socket_check.vi) that use internal validity checking to return TRUE or FALSE depending on whether the supplied object is a valid object.
Cheers,
Martijn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's me again :)
I have another request for you. Could you add error handling to the wrappers (there are some error retminals not connected) or disable automatic error handling. The problem we are having that pop-ups appear and block the execution of the program. (it would be much better if it produced error on the wire, as we can handle this)
Best regards
Blaz
ps. sorry for three separate posts, but I thought it would be better if the issues / requests were separated into topis.
Which functions don't have error handlers connected? Every API call has its error terminals connected to Error In/Error Out in the standard convention. If not then that is an oversight that needs correcting. Unless the DVR blocks are raising error? I've never seen that before. Either way I need you to tell me which function calls are giving you problems.
The examples don't use error handling but they're just examples. Any actual application should definitely handle the Error In/Error Out terminals.
DVR blocks raise errors when, for instance, the socket reference is invalid. Perhaps it would be good to wrap all library calls in error cases.
It would perhaps also be useful to have a "is reference valid" VI available.
Ah I see. It's not actually the library call at all, but the DVR multithreading hack that errors when the input object is invalid. Arguably you should write your ZMQ code to never have invalid objects, but I also accept that the VIs should never interrupt execution at the block diagram if indeed that were to somehow occur. I would argue that if you encounter invalid objects you should rewrite your code to follow the paradigms of the guide more closely - if you can enter a state where sockets are poorly defined then data loss is probable in the worst case, and there is additional book-keeping overhead in the best case.
I just put together the v3.4.1 release where potential errors using the DVR are merged into the standard error stream. I also created two VIs (zmq_ctx_check.vi and zmq_socket_check.vi) that use internal validity checking to return TRUE or FALSE depending on whether the supplied object is a valid object.
Cheers,
Martijn