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
{{ message }}
Repository navigation
All exceptions — including signals — are caught during an observation #60
definitialize(name,experiment, &block)
...
begin@value=block.callrescueObject=>e@exception=eend
...
end
Which is a welldocumentedanti-pattern. In particular, it means that any signals (eg. <SignalException: SIGTERM>) will be treated as-if they were just an error in the candidate code (which usually means logging and ignoring).
Note: There's no difference between rescue Object and rescue Exception because raising a non-exception (eg. a string) will either raise a <TypeError: exception class/object expected> or a <RuntimeError: Some string>.
I think the standard pattern — rescue StandardError — is correct here. That will catch everything except SignalExceptions and other things which aren't meant to be dealt-with as part of standard error handling.
Although users could filter-out all non-StandardError Exceptions themselves, this feels like a footgun (since signals will be relatively rare — especially in development — most users won't notice any problems until they happen in production).
changed the title [-]All exceptions — including signals — are ignored during an observation[/-][+]All exceptions — including signals — are caught during an observation[/+]on Dec 12, 2016
Activity
Don't rescue signals when running experiments
[-]All exceptions — including signals — are ignored during an observation[/-][+]All exceptions — including signals — are caught during an observation[/+]