diff options
author | Jonathan Rochkind <jonathan@dnil.net> | 2012-09-11 10:38:27 -0400 |
---|---|---|
committer | Jonathan Rochkind <jonathan@dnil.net> | 2012-09-11 10:38:27 -0400 |
commit | 5b7cfc5eeae3c5aa8e2ab5e3a0b9bd63b8465168 (patch) | |
tree | 3346ccf8fe26f13dde821871aa1e23022e4b88a3 /guides | |
parent | 616ba15f2cb89588ae3b0a55452f4059f2c118b1 (diff) | |
download | rails-5b7cfc5eeae3c5aa8e2ab5e3a0b9bd63b8465168.tar.gz rails-5b7cfc5eeae3c5aa8e2ab5e3a0b9bd63b8465168.tar.bz2 rails-5b7cfc5eeae3c5aa8e2ab5e3a0b9bd63b8465168.zip |
ConnectionPool, unify exceptions, ConnectionTimeoutError
As a result of different commits, ConnectionPool had become
of two minds about exceptions, sometimes using PoolFullError
and sometimes using ConnectionTimeoutError. In fact, it was
using ConnectionTimeoutError internally, but then recueing
and re-raising as a PoolFullError.
There's no reason for this bifurcation, standardize on
ConnectionTimeoutError, which is the rails2 name and still
accurately describes semantics at this point.
History
In Rails2, ConnectionPool raises a ConnectionTimeoutError if
it can't get a connection within timeout.
Originally in master/rails3, @tenderlove had planned on removing
wait/blocking in connectionpool entirely, at that point he changed
exception to PoolFullError.
But then later wait/blocking came back, but exception remained
PoolFullError.
Then in 02b233556377 pmahoney introduced fair waiting logic, and
brought back ConnectionTimeoutError, introducing the weird bifurcation.
ConnectionTimeoutError accurately describes semantics as of this
point, and is backwards compat with rails2, there's no reason
for PoolFullError to be introduced, and no reason for two
different exception types to be used internally, no reason
to rescue one and re-raise as another. Unify!
Diffstat (limited to 'guides')
0 files changed, 0 insertions, 0 deletions