crash on shared drive becoming unavailable

[philipstarkey]

Original report (archived issue) by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

If the shared drive becomes unavailable BLACS crashes and will not do anything until it is restarted.
This is caused by lines 730-736 and 825-831 trowing exceptions that are not caught.

It would be nice if BLACS would handle this in a away that one could resume experiments (after fixing the problem) without needing to restart BLACS.

[philipstarkey]

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

---

This is a larger problem than just BLACS - there are many points of failure in labscript suite programs where they will not recover well if either the network drive or the network connection to zlock goes down.

At some point I would like to make a wrapper for accessing files that catches errors and pops up a GUI saying "can't access file/can't contact zlock, retrying in " with a button "retry now". The program in question would hang in the meantime, but for situations where it can't reasonably proceed until it accesses the file/zlock, that's really all that can be done, and prevents the program from crashing hard if there is a minor network mishap.

Then for files where failure is an option, exceptions should be caught and dealt with on a case-by-case basis, for example, how lyse marks inaccessible files as such and ignores them. But a first port of call would be auto retrying with the dialog - definitely better default behaviour than a hard crash.

It's on the todo list!