aboutsummaryrefslogtreecommitdiffstats
path: root/rails.gemspec
diff options
context:
space:
mode:
authoreileencodes <eileencodes@gmail.com>2019-07-30 09:06:48 -0400
committereileencodes <eileencodes@gmail.com>2019-08-01 16:33:58 -0400
commitdde03a9234e9b7fe802a45d511720c0ac3bf7617 (patch)
tree7af0a1b82060d9b9635ad615ffc198c5a9e4c03e /rails.gemspec
parent4f1bd290f0d834b30976b6c08bcee9b15c13b2ad (diff)
downloadrails-dde03a9234e9b7fe802a45d511720c0ac3bf7617.tar.gz
rails-dde03a9234e9b7fe802a45d511720c0ac3bf7617.tar.bz2
rails-dde03a9234e9b7fe802a45d511720c0ac3bf7617.zip
Introduce InvalidConfigurationError
In our app at work we had a faked config like this: ``` { "foo" => :bar, "bar" => { "adapter" => "memory" } } ``` This config is invalid. You can't say for foo env just have a symbol, nor would this work if you had fa foo env with just a string. A configuration must be a url or an adapter or a database. Otherwise it's invalid and we can't parse it. When this was just yaml turned into hashes you could get away with passing whatever. It wouldn't work but it wouldn't blow up either. Now that we're using objects we were returning `nil` for these but that just means we either blow up on `for_current_env` or compact the `nil`'s. I think it's a better user experience to not build the configs and raise an appropriate error. This is also an invalid config because if you do pass a string here it should be a URL. ``` { "foo" => "bar", "bar" => { "adapter" => "memory" } } ```
Diffstat (limited to 'rails.gemspec')
0 files changed, 0 insertions, 0 deletions