Inconsistent date errors
When using Date, if you initialize an invalid date you'll get an
Date.new(1999, 1, 32) # => ArgumentError: invalid date
This is as expected.
If you provide
nil as any of the three arguments, you do not get this error. You get three unrelated errors (two NoMethodErrors and one TypeError), none of which are specific to date:
Date.new(1999, 1, nil) # => NoMethodError: undefined method `div' for nil:NilClass Date.new(1999, nil, 32) # => TypeError: no implicit conversion from nil to integer Date.new(nil, 1, 32) # => NoMethodError: undefined method `<' for nil:NilClass
My proposal is that all invalid date initialization cases should raise
ArgumentError: invalid date or some uniform date-specific error. This would make debugging more convenient / user friendly and makes rescuing
ArgumentError actually catch all Date initialization errors. I find it weird that these internal calls error out and are exposed.
Updated by shevegen (Robert A. Heiler) 9 months ago
While I am not sure if ArgumentError for all entries would be the proper
solution, I agree that there may be more elegant solutions to the
above problem set - aka when a nil value is passed as parameter (may
happen accidentally too, if variables are passed, which are set to nil
elsewhere, or have not been initialized).
Perhaps a new error type could be used (such as InvalidDate), but I am also
not sure if this is the proper fix. I agree that it would be more convenient
to tell a user that any of the above would either lead to an invalid date;
or to not error out with three different errors (ArgumentError, NoMethodError,
TypeError). In particular the NoMethodErrors seem to be exposing interals
to the outside, which I do not think is necessary. This is just my opinion
though - I have not really thought a lot about this.