Write a simple, clean error message without a backtrace and exit on failure

Question

I want to write on failure to either STDOUT or STDERR a clean, simple error message for the user, without the (verbose) backtrace, and then exit with a failed status. I am currently using raise to raise exceptions in various parts of the code that I call. I am using begin ... rescue block and abort that wraps the entire caller code as in this simplified example:

#!/usr/bin/env ruby

def find_library_by_id(library_id)
  # ... This code is deleted for brevity ...
end

def aggregate_multiple_comparisons(library_ids)
  property_names = %w[input_volume input_type]
  library_ids.each do |library_id|
    library = find_library_by_id(library_id)
    unless library
      raise "Library with library_id=#{library_id} is not found. Check the input to this script"
    end

    property_names.each do |property_name|
      unless library[property_name]
        raise "Property=#{property_name} not found for library_id=#{library_id}. Check the sample sheet."
      end
    end
    # ... This code is deleted for brevity ...
  end
end

def main
  aggregate_multiple_comparisons([1, 2])
rescue StandardError => e
  abort e.message
end

main if $PROGRAM_NAME == __FILE__

The real-life example has a much more verbose backtrace, and multiple raise statements to handle different failure modes with customized messages. The purpose of the code is to compare quality metrics of multiple genomic sequencing libraries to each other. This purpose is not very relevant to the question I have.

Is this the preferred (e.g., the most maintainable) method to handle exceptions and print just the error message and exit with a failed status?

The other alternative would be, for example, using abort instead of raise in the code, and without the begin ... rescue block.

Answer 1

The abort alternative sounds like a non-starter. What you wrote in the OP seems ideal.

Library code that uses raise is re-usable in many settings. The final rescue in main() captures the essence of the current use case, while leaving the library code flexible for other cases such as a developer needing to see a detailed stack trace, or calling code that knows how to properly recover from or ignore certain errors.