Stack Traces Considered Harmful
I’m trying to build an open source project in a language I’m unfamiliar with and hit this problem:
(base) $ ruby bin/setup == Installing dependencies == A new release of RubyGems is available: 3.6.2 ? 3.6.3! Run `gem update --system 3.6.3` to update your installation. Bundler 2.6.2 is running, but your lockfile was generated with 2.3.9. Installing Bundler 2.3.9 and restarting using that version. Fetching gem metadata from https://rubygems.org/. Fetching bundler 2.3.9 Installing bundler 2.3.9 Your Ruby version is 3.4.1, but your Gemfile specified ~> 3.0.4 bin/setup:16:in 'Kernel#system': Command failed with exit 18: bundle (RuntimeError) from bin/setup:16:in 'block in' from /opt/homebrew/Cellar/ruby/3.4.1/lib/ruby/3.4.0/fileutils.rb:241:in 'Dir.chdir' from /opt/homebrew/Cellar/ruby/3.4.1/lib/ruby/3.4.0/fileutils.rb:241:in 'FileUtils#cd' from bin/setup:10:in '<main>'
This illustrates a common antipattern in error handling. This is a Ruby program, but I’ve encountered it often in Python programs too, including the Google Cloud SDK. It also happens in Java, though less frequently. The most common place it appears in Java is when JUnit tests fail. Do you see it?
Read the rest of this entry »
