try/catch idiom in std.datetime

[Jonathan M Davis]

On Tuesday, November 19, 2013 16:48:30 Dmitry Olshansky wrote:
> It's also interesting to see that some primitives are better be designed
> to work with untrusted input see utf.decode.
> While others are designed not. What I mean by _designed_ is that
> encountering wrong inputs in a correct program is unavoidable and to be
> expected. Also (2) and (3) can be constructed on top of (1) by widening
> the interface.
> 
> Compare hypothetical:
> Date parseDate(string str);
> vs:
> Date date(Year year, Month month, Day day);
> 
> The first better be designed to scrub input, while the second is
> designed to accept verified values (hence Year, Month and not naked ints).

True, though there can still be invalid days depending on the month and year, 
so it's not the case that there can't be bad input even if you no casting to 
Year, Month, or Day was involved. It's one that I debated on and end up going 
with exceptions, because it was consistent with everything else in 
std.datetime to do so, but it could also be argued that asserting would have 
been better in this case. In contrast, as you indicated, parsing a string for 
a date is clearly a case where exceptions are better.

- Jonathan M Davis