Skip to content

Catch RuntimeError when parsing #64

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion lib/cc/engine/analyzers/analyzer_base.rb
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,8 @@ class Base
::Errno::ENOENT,
::Racc::ParseError,
::RubyParser::SyntaxError,
]
::RuntimeError,
].freeze
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


def initialize(engine_config:)
@engine_config = engine_config
Expand Down