All exceptions — including signals — are caught during an observation
- Dominant language
- Ruby
- Stars
- 7.8k
- Forks
- 505
- PR merge metrics
- No merged PRs in 30d
Description
`observation.rb` does this:
```ruby
def initialize(name, experiment, &block)
...
begin
@value = block.call
rescue Object => e
@exception = e
end
...
end
```
Which is a [well](http://daniel.fone.net.nz/blog/2013/05/28/why-you-should-never-rescue-exception-in-ruby/) [documented](http://www.mikeperham.com/2012/03/03/the-perils-of-rescue-exception/) [anti-pattern](https://robots.thoughtbot.com/rescue-standarderror-not-exception). In particular, it means that any signals (eg. ``) 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 `` or a ``.
I think the standard pattern — `rescue StandardError` — is correct here. That will catch everything except `SignalException`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).
Contributor guide
Research direction
Start in observation.rb at the initialize method and inspect the rescue around block.call. Change the exception handling as requested so signals are not treated as candidate-code errors, then verify that standard errors are still captured without swallowing signals.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 52/100