On Monday, November 18, 2013 14:45:54 Andrei Alexandrescu wrote: > 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. > > 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.
+1 - Jonathan M Davis
