Example of writing code for exception handling in Ruby, and ruby Exception Handling

Ruby exception handling code writing example, ruby exception handling

A single exception uses the fail keyword only when catching an exception and repeatedly throwing the exception (because you are not failing here, but accurate and intentionally throwing an exception).

  begin
   fail 'Oops'
  rescue => error
   raise if error.message! = 'Oops'
  end

    Do not specify an accurate RuntimeError for fail / raise.

   

 # bad
  fail RuntimeError, 'message'

  # good-signals a RuntimeError by default
  fail 'message'

    Rather than provide an exception class and a message as two fail / raise parameters, rather than an exception instance.

   

 # bad
  fail SomeException.new ('message')
  # Note that there is no way to do `fail SomeException.new ('message'), backtrace`.

  # good
  fail SomeException, 'message'
  # Consistent with `fail SomeException, 'message', backtrace`.

    Don't return in the ensure block. If you explicitly return from a method in the ensure block, the return will be better than any exception thrown, and will return even if no exception is thrown. In fact, the anomaly will slip away quietly.

  

 def foo
   begin
    fail
   ensure
    return 'very bad idea'
   end
  end
    Use implicit begin blocks when possible. If implicit begin blocks are used.

   

 # bad
  def foo
   begin
    # main logic goes here
   rescue
    # failure handling goes here
   end
  end

  # good
  def foo
   # main logic goes here
  rescue
   # failure handling goes here
  end

    Through contingency methods. (A word coined by Avdi Grimm) to reduce the use of begin blocks.

 

  # bad
  begin
   something_that_might_fail
  rescue IOError
   # handle IOError
  end

  begin
   something_else_that_might_fail
  rescue IOError
   # handle IOError
  end

  # good
  def with_io_error_handling
    yield
  rescue IOError
   # handle IOError
  end

  with_io_error_handling {something_that_might_fail}

  with_io_error_handling {something_else_that_might_fail}

    Do not suppress abnormal output.

 

  # bad
  begin
   # an exception occurs here
  rescue SomeError
   # the rescue clause does absolutely nothing
  end

  # bad
  do_something rescue nil

    Avoid using the modifier form of rescue.

   

 # bad-this catches exceptions of StandardError class and its descendant classes
  read_file rescue handle_error ($!)

  # good-this catches only the exceptions of Errno :: ENOENT class and its descendant classes
  def foo
   read_file
  rescue Errno :: ENOENT => ex
   handle_error (ex)
  end

    Don't use exceptions to control the flow.

   

 # bad
  begin
   n / d
  rescue ZeroDivisionError
   puts "Cannot divide by 0!"
  end

  # good
  if d.zero?
   puts "Cannot divide by 0!"
  else
   n / d
  end

    You should always avoid intercepting the (topmost) Exception class. Here (ruby itself) will capture the signal and call exit, which requires you to kill the process using kill -9.

 

  # bad
  begin
   # calls to exit and kill signals will be caught (except kill -9)
   exit
  rescue Exception
   puts "you didn't really want to exit, right?"
   # exception handling
  end

  # good
  begin
   # a blind rescue rescues from StandardError, not Exception as many
   # programmers assume.
  rescue => e
   # exception handling
  end

  # also good
  begin
   # an exception occurs here

  rescue StandardError => e
   # exception handling
  end

    Put more specific exceptions above the rescue chain, otherwise they will not be rescued.

  # bad
  begin
   # some code
  rescue Exception => e
   # some handling
  rescue StandardError => e
   # some handling
  end

  # good
  begin
   # some code
  rescue StandardError => e
   # some handling
  rescue Exception => e
   # some handling
  end

    Release the external resources obtained by your program in the ensure block.

  

 f = File.open ('testfile')
  begin
   # .. process
  rescue
   # .. handle error
  ensure
   f.close unless f.nil?
  end
    Unless necessary, use exception classes from the Ruby standard library whenever possible, rather than introducing a new exception class. (Instead of deriving your own exception class)