similar concepts, different syntax Ruby Exceptions similar concepts, different syntax

So what about Ruby?* Exceptions are raised using the raise method of Kernel The rescue clause is used to handle exceptions Exceptions are instances of the Exception class (or a subclass) Subclasses do not add methods or behavior, but allow exceptions to be categorized Most exceptions extend StandardError Other exceptions are low-level, typically not handled by programs * Exception info directly from The Ruby Programming Language

Getting info message method returns a string – more suitable for programmers than end users backtrace returns the call stack array of strings filename : linenumber in methodname

raising an exception fail is synonym (use if expect program to end) Several ways to invoke raise: with no arguments. If inside rescue, re-raises same exception, otherwise raises RuntimeError with single Exception object. Not common. with single String argument. Creates RuntimeError with that string as message. Very common. with exception object, string (for message) and array of strings (for backtrace).

Example def factorial(n) raise "bad argument" if n < 1 # raise ArgumentError if n < 1 # raise ArgumentError, "Expected argument >= 1, got #{n}" if n < 1 return 1 if n == 1 n * factorial(n-1) end Can provide a custom stack trace def factorial4(n) if n < 1 raise ArgumentError, "Expected argument >= 1, got #{n}", caller

capturing an exception rescue is part of Ruby language (not a Kernel method) clause that can be attached to other Ruby statements typically attached to begin begin # statements, possible exceptions rescue # code to deal with exceptions end # if no exception, code continues here, code in rescue is not executed

handling the exception rescue handles any StandardError global variable $! refers to raised exception better to specify variable in rescue begin x = factorial(0) rescue => ex puts "#{ex.class}: #{ex.message}" end

handling multiple types def factorial5(n) raise TypeError, “Need integer" if not n.is_a? Integer raise ArgumentError, “Need argument >= 1, got #{n}" if n < 1 return 1 if n == 1 n * factorial(n-1) end begin x = factorial5("a") rescue ArgumentError => ex puts "Try again with argument > 1" rescue TypeError => ex puts "Try again with an integer" Does the order matter?

propagating exceptions def explode raise "bam!" if rand(10) == 0 end def risky begin 10.times do explode #raises error ~10% of time rescue TypeError # won't catch RuntimeError puts $! end # RuntimeError not handled, will propagate "hello" # if no exception def defuse puts risky rescue RuntimeError => e # handle propagated error puts e.message defuse QUICK EX: Trace code

Other options retry – with rescue, reruns block of code that rescue is attached to. Useful for transient failures such as overloaded server. Be sure to limit number of retries. ensure – code that always runs, for housekeeping like disconnecting from database, closing files, etc. not covered: subtle details for ensure rescue can be used as a statement modifier (y = factorial(x) rescue 0 #returns 0 if error)

throw/catch similar to a labeled break, but can break out of multiple levels not used for exception handling used infrequently, details not covered