You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the pysmurf.client code that implements low level EPICS caget and caput commands without handling exceptions. So, when a exception if raise by the pyepics layer, the pysmurf.client code is halted.
T avoid this, the code that implements caget and caput calls need to wrap those call in try-catch statements and handle the exception accordingly.
To Reproduce
I don't know a way to reproduce this type if issues, but this is the client backtrace of an instance when this happened:
In this example, pyepics raised a CASeverityException exception here which has not handled by the client code and the script stop.
A similar situation can happened also during a register write, i.e. during a caput call.
Expected behavior
Exception should be caught, and handle, maybe retrying the call by a maximum number of time, similar to the solution to #589.
For example, something like this example (which combines the solution for #589):
n_retry=0success=FalsewhileTrue:
try:
ret=epics.caget(cmd, count=count, **kwargs)
ifret:
# If ret is not None, mark the call as succeed success=Trueelse:
# Log the errorifwrite_log:
self.log(f'"epics.caget({cmd}) returned None."')
exceptExceptionase:
# Catch any type exception coming from pyepics, and log it.ifwrite_log:
self.log(f'Exception during a "epics.caget({cmd})" call: {e}')
# If the pyepics.caget succeeded, break the loop and continue.ifsuccess:
break# If the pyepics.caget failed (either by raising and exception, or returning None),# but we should not retry on error, or if we reached the maximum number if retries,# stop the script by raising an exceptionifnotretry_on_failorn_retry>=max_retry:
# Give a different error log message depending on the reason we stopped.ifnotretry_on_failerror_msg=f'"epics.caget({cmd})" failed, but we are not retrying...'else:
error_msg=f'Maximum number of retires reach during a "epics.caget({cmd})"'# Write the log messageifwrite_log:
self.log(error_msg)
# Raise and exception to stop the scriptraiseRuntimeError(error_msg)
# Otherwise, we retry the callifwrite_log:
self.log(f'Retry "epics.caput({cmd})"" attempt {n_retry+1} of {max_retry}')
# "epics.caget" succeed.Continue with the rest of the script.ifwrite_log:
self.log(ret)
and something similar for the epics.caput call as well.
The text was updated successfully, but these errors were encountered:
@slacrherbst Hey Ryan ; sorry, I lost this thread ; I had thought we agreed that it wasn't possible to catch EPICS exceptions but maybe that's not right. Should we implement this proposed fix?
Describe the bug
Currently the pysmurf.client code that implements low level EPICS
caget
andcaput
commands without handling exceptions. So, when a exception if raise by thepyepics
layer, the pysmurf.client code is halted.T avoid this, the code that implements
caget
andcaput
calls need to wrap those call intry-catch
statements and handle the exception accordingly.To Reproduce
I don't know a way to reproduce this type if issues, but this is the client backtrace of an instance when this happened:
In this example,
pyepics
raised aCASeverityException
exception here which has not handled by the client code and the script stop.A similar situation can happened also during a register write, i.e. during a
caput
call.Expected behavior
Exception should be caught, and handle, maybe retrying the call by a maximum number of time, similar to the solution to #589.
For example, something like this example (which combines the solution for #589):
and something similar for the
epics.caput
call as well.The text was updated successfully, but these errors were encountered: