mirror of
https://github.com/isc-projects/bind9.git
synced 2026-02-18 01:58:49 -05:00
71c6d40942
We should drop the HISTORY file because it's confusing and the same information is covered by the release notes for .0 releases (or at least they should be). Remove references to the HISTORY file, update the README to tell people go look somewhere else.
29 lines
1.3 KiB
Text
29 lines
1.3 KiB
Text
Design By Contract
|
|
|
|
BIND 9 uses the "Design by Contract" idea for most function calls.
|
|
|
|
A quick summary of the idea is that a function and its caller make a
|
|
contract. If the caller meets certain preconditions, then the
|
|
function promises to either fulfill its contract (i.e. guarantee a set
|
|
of postconditions), or to clearly fail.
|
|
|
|
"Clearly fail" means that if the function cannot succeed, then it will
|
|
not silently fail and return a value which the caller might interpret
|
|
as success.
|
|
|
|
If a caller doesn't meet the preconditions, then "further execution is
|
|
undefined". The function can crash, compute a garbage result, fail silently,
|
|
etc. Allowing the function to define preconditions greatly simplifies many
|
|
APIs, because the API need not have a way of saying "hey caller, the values
|
|
you passed in are garbage".
|
|
|
|
Typically, preconditions are specified in the functions .h file, and encoded
|
|
in its body with REQUIRE statements. The REQUIRE statements cause the program
|
|
to dump core if they are not true, and can be used to identify callers that
|
|
are not meeting their preconditions.
|
|
|
|
Postconditions can be encoded with ENSURE statements. Within the body of
|
|
a function, INSIST is used to assert that a particular expression must be
|
|
true. Assertions must not have side effects that the function relies upon,
|
|
because assertion checking can be turned off.
|
|
|