Open thchwhite opened 10 years ago
Evan, didn't you already add a "synchronous" option to help make the tracebacks more helpful?
Assigned to Evan because I think he already did this. Evan, if you don't want to deal with this just un-assign it.
If you construct a packet with the sync=True keyword argument, it will execute all remote calls synchronously, generating exceptions for errors in the appropriate location. However, it only works with the normal client code, not asynchronous (GUI) clients or servers acting as clients. There doesn't seem to be a simple way to extend it to these situations.
Well, I think we could fix up the backend code to wait on all async calls.
On Sun, Aug 17, 2014 at 8:59 PM, ejeffrey notifications@github.com wrote:
If you construct a packet with the sync=True keyword argument, it will execute all remote calls synchronously, generating exceptions for errors in the appropriate location. However, it only works with the normal client code, not asynchronous (GUI) clients or servers acting as clients. There doesn't seem to be a simple way to extend it to these situations.
— Reply to this email directly or view it on GitHub https://github.com/martinisgroup/pylabrad/issues/27#issuecomment-52449257 .
Daniel Sank Department of Physics Broida Hall University of California Santa Barbara, CA 93117 (805)893-3899
What about errors on the server side? Is there a good way to ensure that those always get displayed appropriately?
What about errors on the server side? Is there a good way to ensure that those always get displayed appropriately?
Sure. We just need to find it.
It would be very helpful if pylabrad could be modified to give more detailed error reporting information. A specific example of this would be for unit errors. We have been porting over a lot of the old servers, and it would be helpful if pylabrad tracebacks could somehow carry more information about where in the code the error was first generated.