From: "ara.t.howard" Date: 2007-11-09T12:43:19+09:00 Subject: Re: Best practises for exception handling On Nov 8, 2007, at 7:20 PM, Joel VanderWerf wrote: > 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/ -- share your knowledge. it's a way to achieve immortality. h.h. the 14th dalai lama