Run-Time vs. Config-time error checking controls

[Jason Kraftcheck]

On 10/21/2010 12:53 PM, Mark Miller wrote:
> On Thu, 2010-10-21 at 10:26, Jason Kraftcheck wrote:
> 
>>> All the arguments for strict checking seem
>> to center around helping developers avoid accidentally doing things that are
>> not guaranteed to work with all implementations.  While people may think
>> that this is a good practice, mandating that our implementation conform to
>> this practice seems well beyond the scope of the API specification.
> 
> Why do we define iBase_ErrorType in iBase.h, then? Why don't we just let
> all implementations decide what error codes to return or whether to
> return any error code at all when the caller does something wrong or
> something they shouldn't have or something that is 'not portable across
> all implementations' (look for a follow-up email on this).
> 

That is a somewhat disingenuous argument.  If we're going to provide error
codes at all then clearly the definition of those error codes belongs in the
API spec.  Otherwise code that checked for errors wouldn't even compile if
used with a different implementation (if we can't even guarantee that then
our API spec has some issues).  And clearly if any implementation returned
success when an operation failed then that implementation has a bug.   That
is quite different from strong requirements on when an implementation must
return an error code (if it things it can successfully do something.)

> I think specifying how the API responds to 'wrong' or 'erroneous'
> actions by the caller is part of the API specification. In some cases,
> its essential for implementors and users alike to know this. In other
> cases, maybe the current issue at hand, it is not as critical.
> 

Well, now you've changed the discussion from how an implementation handles
failures to mandating what must be considered a "wrong" action on the part
of the caller.

- jason