Another possibility, somewhere between a and b: rescue the
exception and re-raise, but add some more information to the
message. That extra info might be, for example, IP address and port
during network operations. This doesn't change the structure of
exception handling, since the Exception subclass is the same and it
will be handled at the same point, eventually, but it can be very
useful for logging/debugging and for presenting an informative
message to the user, if your program is interactive.
good point joel, i recently added this to main:
...
rescue Exception => e
handle_exception e
end
...
def handle_exception e
if e.respond_to?
error_handler_before)
fcall(e, :error_handler_before, self)
end
if e.respond_to?
error_handler_instead)
fcall(e, :error_handler_instead, self)
else
if e.respond_to? :status
exit_status(( e.status ))
end
if Softspoken === e or SystemExit === e
stderr.puts e.message unless(SystemExit === e and
e.message.to_s == 'exit') ### avoids double message for abort('message')
else
fatal{ e }
end
end
if e.respond_to?
error_handler_after)
fcall(e, :error_handler_after, self)
end
exit_status(( exit_failure )) if exit_status == exit_success
exit_status(( Integer(exit_status) rescue(exit_status ? 0 : 1) ))
exit exit_status
end
...
which basically allows exceptions to be extended with modules or have
methods defined on them which affect how they are handled. it seems
like a useful pattern but i've only just started using it.
cheers.
a @
http://codeforpeople.com/