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
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).
The text was updated successfully, but these errors were encountered:
`rescue Object` is equivalent to `rescue Exception`, which will catch signals and other messages which shouldn't be silenced during an experiment.
See github#60
djrodgerspryor
changed the title
All exceptions — including signals — are ignored during an observation
All exceptions — including signals — are caught during an observation
Dec 12, 2016
observation.rb
does this:Which is a well documented anti-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
andrescue 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 exceptSignalException
s 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).
The text was updated successfully, but these errors were encountered: