Issue #15298 has been updated by shevegen (Robert A. Heiler).


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, 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.

----------------------------------------
Misc #15298: Inconsistent date errors
https://bugs.ruby-lang.org/issues/15298#change-74842

* Author: gollahon (Daniel Gollahon)
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
When using Date, if you initialize an invalid date you'll get an `ArgumentError`:

```ruby
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:

```ruby
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.

Thanks,
Daniel



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>