When I first started developing right after college in C++ and came across an error, I used to follow the common pattern of trying to take what seemed like the best action to avoid crashing. Later, I learned about the concept of “Fail Fast and Early” – where if an error exists, you want to fail and identify it ASAP. That way, you can correct it early on instead of just masking it.
Surprisingly to me, Rails seems to adopt the former approach.
You want to create a date with invalid input? No problem, we’ll just set it to today and never complain. Want to convert the string “abc” to be an integer? No problem, we’ll just set it to zero and not a peep from us. You want to update an ActiveRecord integer field to a float? No worries, we’ll just silently drop the decimal portion.
Of course, sometimes (often, actually), you want to inform the user when they have supplied invalid input to take corrective action.
So, if the date is set to today or the integer has a value of 0, then you know you have a problem. Except that these are also valid values. Surely there must be a method on these things you can invoke to see if their string representations are valid, right? Er, I mean they must be, somewhere, because of course it would exist, right?
I have a string, and I want to see if this string is an integer or float. Surely, there is a method I can use. There is, as long as you write it yourself as I did via regex.
If Rails is going to auto-convert erroneous inputs, it could at least provide a mechanism to detect invalid inputs.
In Java, if you try to create an Integer from the string “abc”, it will immediately fail with an exception so you a) know what is wrong, and b) have a good mechanism for recovering. In Ruby, I can create a date from “3/23/sdes” without complaint (hint – it resolves to 3/23 of this year).
I am sure there is Ruby/Rails philosophy which drives this approach, but I just don’t know what it is yet. For the moment, it is making UI-based validation a lot more difficult than it should be.