Catch RuntimeError when parsing

[wfleming]

RubyParser raises RuntimeError instead of anything more specific in
certain parse error contexts.

Thoughts, @codeclimate/review? I don't like catching this low-level an exception, but it's pretty localized at least, so it's not the worst.

I've also reviewed the RubyParser code & haven't turned up any other likely candidates.

[ABaldwinHunter]

Curious about what errors - if any - we'd want to make sure aren't rescuable? And why this engine seems to have a bit more error catching than others?

[wfleming]

One important case we don't want to rescue is timeouts parsing individual files: we found that previously the timeout values were set low enough that GC-jitter/resource pressure/etc. could cause a file to timeout on some runs & not others (leading to inconsistent results). So the timeout values have been greatly heightened to the point where they indicate real problems, and we don't want to catch them because they indicate a file should be excluded/there's a more severe parser bug that deserves investigation. The problems caused by this is why we moved away from the prior behavior, which did catch basically all exceptions.

Beyond that, I'm still of the opinion that exceptions can & normally should indicate bugs that need fixing, and when they're caught/handled we should be as precise as possible about what we're catching. Otherwise we're potentially just hiding bugs. In this particular case we're intentionally hiding bugs in a dependency (RubyParser, etc.), which isn't great, but seems like the lesser of the evils available to us.

[ABaldwinHunter]

One question but LGTM

[wfleming]

Bleh. Just realized that exception classes we don't want to rescue (e.g. Timeout::Error inherit from RuntimeError). So this isn't going to work. Closing this to take another approach.