try/catch idiom in std.datetime

[Dmitry Olshansky]

19-Nov-2013 02:45, Andrei Alexandrescu пишет:
> On 11/18/13 2:04 PM, Walter Bright wrote:
>> On 11/18/2013 1:02 PM, Jacob Carlborg wrote:
>>> I really don't understand the point in having some functions thrown
>>> and others
>>> assert.
>>
>> That's a red flag that there is a faulty design somewhere, in this case
>> I think it's not having a separation between input data validation and
>> program bug detection.
>
> The question is what's "program" and what's "input". Consider:
>
> int a = fun();
> std.gun(a);
>
> There are two possible takes on this:
>
> 1. The standard library is considered part of the user's program, and
> the whole thing is a unit. In that case, passing the wrong int to
> std.gun is an PROGRAM error and 100% blame goes to the programmer who
> wrote the caller code. In that case, assert/assert(0)/contracts are the
> appropriate constructs to be used inside std.gun.
>
> This is the approach taken by the C standard library, which is free to
> do whatever it wants (including crashing the program) upon calls such as
> strlen(NULL) etc.
>
> 2. The standard library is a separate entity from the PROGRAM, and as
> far as it cares, any data from the user is INPUT. So the standard
> library with SCRUB the input, in which case enforce() and throwing
> exceptions are appropriate.
>

3. The standard library handles all input, the wrong input is eliminated 
as a class by providing meaningful output on error. So called 
soft-errors. An example would be returning a 0xFFFD when decoding a 
broken UTF-8 codepoint. Arguably bad examples include fopen/malloc 
returning 0.

All three cases can and should be judiciously mixed and matched.

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


-- 
Dmitry Olshansky