Documentation Source Text

Check-in [ef3822f76d]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Further clarification to the assert.html document.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | branch-3.28
Files: files | file ages | folders
SHA3-256: ef3822f76da5b93d539eefd0c1c3c72016656172a530db20a97ba92baac4e451
User & Date: drh 2019-04-29 19:27:41.532
Context
2019-04-30
20:15
Further enhancements to the whynotgit.html page. (check-in: 763fc99770 user: drh tags: branch-3.28)
2019-04-29
19:27
Further clarification to the assert.html document. (check-in: ef3822f76d user: drh tags: branch-3.28)
15:46
Soften the criticism of Go because of their decision to omit assert() from the language. (check-in: 4a40995c05 user: drh tags: branch-3.28)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/assert.in.
︙︙
69
70
71
72
73
74
75
76
77
78
79


80


81
82
83
84
85
86
87
88
89
90

actually deal with the problem when the programmers reasoning
turns out to be wrong.  Since the code that follows ALWAYS(X) or NEVER(X)
is untested, it should be something very simple, like a "return" statement,
that is easily verified by inspection.

<p>
Because assert() can be and is commonly misused, some programming language
theorists and designers look with disfavor on the whole idea of assert().
For example, the [https://golang.org|Go programming language] omits assert().
The Go developers
[https://golang.org/doc/faq#assertions|recognize this is contentious].


The SQLite developers agree with those that think the decision to 


omit assert() from Go is a mistake.
It is true that assert() can be misused.  Antibiotics can be misused
too, but that does not mean we should ban all antibiotics.

<h2>Different Behaviors According To Build Type</h2>

<p>Three separate builds are used to validate the SQLite software.
<ol>
<li> A functionality testing build is used to validate the source code.
<li> A coverage testing build is used to validate the test suite, to confirm








|
|
<
|
>
>
|
>
>
|
<
<








69
70
71
72
73
74
75
76
77

78
79
80
81
82
83
84


85
86
87
88
89
90
91

actually deal with the problem when the programmers reasoning
turns out to be wrong.  Since the code that follows ALWAYS(X) or NEVER(X)
is untested, it should be something very simple, like a "return" statement,
that is easily verified by inspection.

<p>
Because assert() can be and is commonly misused, some programming language
theorists and designers look upon it with disfavor.
For example, the designers of the [https://golang.org|Go programming language] 

intentionally [https://golang.org/doc/faq#assertions|omit a built-in assert()].
They feel that the harm caused by misuse of assert()
outweighs the benefits of including it as a language built-in.
The SQLite developers disagree.  In fact, the original purpose of this
article is to push back against the common notion that assert() is harmful.
In our experience, SQLite would be much more difficult to develop, test,
and maintain without assert().



<h2>Different Behaviors According To Build Type</h2>

<p>Three separate builds are used to validate the SQLite software.
<ol>
<li> A functionality testing build is used to validate the source code.
<li> A coverage testing build is used to validate the test suite, to confirm
︙︙