Re: Contract Programming 101
Posted: Jan 24, 2006 3:58 PM
> This is not true for return values. Return values are
> never transparent to any application code. Application
> code always needs to know what to expect and what a
> specific return value does mean.
well, you could ignore the return-value.
> This is a fundamental difference between exceptions and
> return values. Now, you can start to model the behaviour
> of exceptions by using return values in a certain
> consistent way in your application code. Granted, this
> will never be really transparent to your application, but
> you do create a kind of metalevel code upon which you
> build your application. The better choice, though, is
> native support in the language, the way exception
> mechanisms provide. You can also start to model the
> behaviour of return values by using exceptions. You just
> need to define which exceptions you throw upon which
> conditions and stop using return values for the named
> cases. Clients of function/method interfaces are forced to
> handle exceptions instead of return values. You obtain the
> very same effect like you used return values.
> So, when don't you use exceptions as a replacement for
> return values? When, as an implementor of a
> function/method interface, you do not name/document the
> exceptions you throw.
right, but you probably document whether the functions can throw or not.
> Because, if you do, these are not
> really transparent to the application code anymore. If
> code is aware of and behaves depending on the concrete
> types of exception thrown by called code, the transparency
> is gone, the exceptions become part of the contract and
> could as well be modeled by usage of return values.
Your views are quite reasonable. If an exception is not documented, it is not part of the contract.
I think I had two points with my original post
1. even if you don't know what exception is thrown, knowing that one can be thrown or not is part of the contract
2. even if you don't know what exception is trown, knowing the state of some relevant objects if it is thrown may be part of the contract