Be a little more discerning about which exceptions to handle

That sounds good. Could you please update a .diff file using git-format-patch ?

Thanks.

Hey guys,

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).