The Right Approach to Exceptions

[Jonathan M Davis]

On Friday, February 24, 2012 07:57:13 H. S. Teoh wrote:
> Actually, I wonder if it makes sense for the compiler to insert
> in-contract code in the *caller* instead of the callee. Conceptually
> speaking, an in-contract means "you have to fulfill these conditions
> before calling this function". So why not put the check in the caller?
> 
> Similarly, an out-contract means "this function's return value will
> satisfy these conditions" - so let the caller verify that this is true.
> 
> Semantically it amounts to the same thing, but this gives us more
> flexibility: the library doesn't have to be compiled with contracts
> on/off, the contracts are in the library API, and the user tells the
> compiler whether or not to wrap the contract code around each call to
> the library.
> 
> (Yes this bloats the code everywhere a DbC function is called, but this
> is supposed to be done in non-release builds only anyway, so I don't
> think that matters so much.)

It wouldn't work unless the source were available, because otherwise you just 
have the function signature. So, the result would be inconsistent, and in the 
case of non-templated functions built against a non-release version of the 
callee, you'd end up having the checks twice, because the callee would have to 
have them regardless (since it's compiled separately, and not every function 
calling it would necessarily have its source). For templated functions, it 
already depends on the caller whether the assertions are enabled, because it's 
instantiated when the module with the caller in it is built. It's an 
interesting idea though.

- Jonathan M Davis