Rails core - May 2010 - Be more discriminating in rescue and wrapping with StatementInvalid

Hi all,

I just submitted a patch to 2-3-stable on lighthouse and wanted to
bring it to folks general attention.

https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/896-be-a-little-more-discerning-about-which-exceptions-to-handle

My explanation is a bit long-winded, but here''s the motivation for the
patch, as explained in the lighthouse ticket:

Perhaps I should open another ticket for this, please let me know if
that''s the case. I have a patch that addresses what is for me the most
egregious case of overeager exception handling. In activerecord/lib/
active_record/connection_adapters/abstract_adapter.rb the #log method
rescues Exception and then re-raises as an
ActiveRecord::StatementInvalid exception.

Some people have hit this problem when they have slow queries that are
hanging the system and so I think the response is generally "fix your
query". But we''re hitting this problem when we try to exit out of
our
background processes that are just cranking through a whole bunch of
data processing.

In these background processes we have designed them to be tolerant to
exceptions and expect the process to die when it''s sent a SIGINT or
SystemExit. However, we also want those processes to stay alive and
continue on to the next job in the queue if any particular job hits an
unexpected exception. So we take the approach of wrapping our job
invocations in a ''rescue Exception'' block and re-raising
(allowing the
process to die) in the case where the exception is a SystemExit or
SignalException. So the AR approach of rescuing and re-raising as a
StatementInvalid breaks this approach and leaves us in a situation
where we have to do resort to less reliable methods of inspecting the
rescued exceptions, like parsing the exception message. It also leads
to confusing behavior where you sometimes see the process die cleanly
(when it''s not invoking an AR statement at the time the SystemExit is
received) or continue running (when the exception was caught and re-
wrapped).

I''m guessing there are other folks out there how are experiencing
similar problems and so I''d like to offer a patch that applies against
the 2-3-stable branch (rather than 3.x).

Cheers,
Andrew

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.