Contracts or Exceptions?

[Kai Meyer]

On 03/29/2011 12:40 PM, Mike Linford wrote:
> Hello,
>
> So I'm writing a function for a library. It takes a struct as an
> argument. The struct's fields can't just be any old values, though. The
> function won't work if some of the fields are weird. It could return an
> erroneous value, or even crash.
>
> The thing is, though, that I can't tell whether the best approach is to
> use an in-contract or throw an exception if it doesn't pass my test. What
> would you guys recommend?
>
>
>

I was given two words of advice on exceptions:
"Use exceptions for the exceptional"
"Use exceptions only for the exceptional"

Meaning, if you expect something to fail frequently, using a try/catch 
is much more expensive than an if/else. "The exceptional" is something 
that should rarely ever occur, like running out of memory.

For contracts, they are usually meant as a developer tool to warn them 
when that they will be in no-man's land if they attempt to proceed any 
further. They are, therefore, not compiled in when you pass the D 
compiler the -release flag.

I don't think that contracts and exceptions are mutually exclusive. They 
provide two different safeguards. One is a tool to aid in the 
development process, one is a tool to safeguard against exceptional 
run-time scenarios.

However, I think if I rephrase your question a little bit, it might 
provide you what I think you're after. I'm making an assumption here, so 
I may be way off the mark.

"Who's responsibility is it to check whether or not the data passed into 
the function is valid? Should I accept whatever the user wants to pass 
in, and let them know when it's invalid, or should I trust that the user 
is sending in good data?"

I think that's a choice for you to make. Contract programming is often 
used to put the burden of validation on the user of the library (meaning 
programmer writing software taht uses your library). Exceptions could be 
used to indicate that the library writer is accepting responsibility for 
validating the data before using it.

But validating data is not the only reason to use exceptions, and it's 
not unusual for a library to skip all validations and force the user to 
do all the checking before hand. Arrays are a good example. When not in 
-release mode, array boundaries are checked upon every access to the 
array, and an exception is thrown if access goes out of bounds. In 
-release mode, if you go out of bounds you get a segfault. This is one 
example of giving the user (programmer) of arrays the responsibility to 
check boundaries so that the library can focus on being fast.

I think the choice comes down to a balance between performance, 
responsibility, and maintainability. (Oh, and you'll usually get it 
wrong the first time, so don't be sad.)