try/catch idiom in std.datetime

Jacob Carlborg doob at me.com
Mon Nov 18 23:52:49 PST 2013


On 2013-11-18 23:45, Andrei Alexandrescu wrote:

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

In D, we can start by saying that all private and package functions 
should use asserts.

> 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.
>
> This is the approach taken by the Windows API, Java, C#, and to a good
> extent the newer parts of C++'s standard library.
>
> To claim that one approach is exactly right and the other is exactly
> wrong would miss important insights.

I agree, it's not easy to just pick one. Say you have a library that 
queries a database. Is it the user's responsibility to validate any 
input that it doesn't contain SQL injections. Or should the library do that?

I would say that it would be quite cumbersome and verbose to for the 
user to constantly validate the input. If the library didn't validate 
the user would most likely create a wrapper function that does this. 
Most users would want to have a function like this and implement it. 
When we come to this, one can ask, isn't this the job of the library? If 
every user needs it, shouldn't it be put in the library?

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list