Run-Time vs. Config-time error checking controls

[Tim Tautges]

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

I agree with this.  However, I think the issue here is what some (Jason and I) believe is an over-zealous effort to 
disallow behavior in some implementations because it's outside some peoples' current understanding of what's useful 
today.  So some people can't imagine an application that would use this capability; does somebody know of a real, 
not-contrived, case where an application had a problem with this?  Does anybody know of a case where an application was 
turned off by inconsistency in the details between implementations?  I can point to one of our (ITAPS') services that 
had trouble with this (swapping and lack of intermediate-dimension entities), but in that case we accommodated the 
various implementations, rather than disallowing specialized behavior.

And on the subject of whether to change names, honestly, we're 9 years into a 10 year effort, and (some would say) 
already suffering from lack of uptake by applications.  Changing names at this point won't help with that problem. 
Similarly, our problem isn't inconsistency between implementations that is being experienced by applications; it's there 
not being any or enough applications in the first place.  Cutting the legs out of an implementation (i.e. disallowing 
the use of one of it's already-supported capabilities) doesn't send us in the right direction, IMO.

- tim

> Mark
>

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706