bluesky / ophyd

hardware abstraction in Python with an emphasis on EPICS
https://blueskyproject.io/ophyd
BSD 3-Clause "New" or "Revised" License
51 stars 79 forks source link

v2: Devices with a mixture of timing-out and erroring signals throw some exceptions away #1153

Open callumforrester opened 1 year ago

callumforrester commented 1 year ago

Say I have a device with two signals, one fails to connect with a timeout, the other immediately raises an error when connect is called. The latter error is not logged. If the timing out signal is subsequently fixed, then the error signal will be logged if I try to connect again.

This may be a good thing as it prevents too much log spam. It may be beneficial to work through the errors one-at-a-time, continually re-running the program and solving the next error until there are none left. Opinions on this point are welcome.

Even if we chose to leave the error un-logged, we should still fix the annoying spam that comes from asyncio because the exception is not handled.

Task exception was never retrieved
future: <Task finished name='Task-4' coro=<DummyDeviceThatTimesOutWhenConnecting.connect() done, defined at ophyd/v2/tests/test_core.py:207> exception=NotConnected('source: foo')>
Traceback (most recent call last):
  File "ophyd/v2/tests/test_core.py", line 209, in connect
    await asyncio.Future()
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "ophyd/v2/tests/test_core.py", line 211, in connect
    raise NotConnected("source: foo")
ophyd.v2.core.NotConnected: source: foo