Misc #15298

Inconsistent date errors

Added by gollahon (Daniel Gollahon) 5 months ago. Updated 5 months ago.



When using Date, if you initialize an invalid date you'll get an ArgumentError:, 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:, 1, nil)  # => NoMethodError: undefined method `div' for nil:NilClass, nil, 32) # => TypeError: no implicit conversion from nil to integer, 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) 5 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.

Also available in: Atom PDF