-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v2: Should we handle errors from signals that don't handle CancelledError
#1152
Comments
Could I ask where this code snippet is from? I thought |
It's not directly from the code, it is a highly simplified version of |
The reason behind |
Currently in v2 signals are expected to handle
CancelledError
on timeout and raiseNotConnected
If we do not do this, then a timeout results in the whole program crashing with
CancelledError
. It is an easy mistake to make and a hard one to solve if the user has not read all of the documentation. It might be worth trying to come up with a more robust design.In GDA, authors of new
Scannable
s are expected to handleInterruptedException
themselves. If they do not, scans do not behave as expected and can become deadlocked and unkillable. ManyScannable
s were written without handling the exception leading to strange and hard-to-diagnose behaviour. We should nip the same problem in the bud here.Paging @coretl @evalott100 @RAYemelyanova and @danielballan
The text was updated successfully, but these errors were encountered: