The Right Approach to Exceptions

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Feb 24 11:13:36 PST 2012


On Fri, Feb 24, 2012 at 01:46:56PM -0500, Jonathan M Davis wrote:
> 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.
[...]

In my mind, contract code belongs in the function signature, because
they document how the function expects to be called, and what it
guarantees in return. It doesn't seem to make sense to me that contracts
would be hidden from the user of the library. Sorta defeats the purpose,
since how is the user supposed to know what the function expects? Rely
on documentation, perhaps, but docs aren't as reliable as actual
contract code.


T

-- 
Без труда не выловишь и рыбку из пруда. 


More information about the Digitalmars-d mailing list