Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Tweaks to the new assert documentation. |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
19d3bdb7e33eb3066f59e30600eac85e |
| User & Date: | drh 2018-03-23 17:50:33 |
Context
|
2018-03-23
| ||
| 18:18 | Cross-reference whyc.html to the HN and Reddit comments. (check-in: a8bc3a4771 user: drh tags: trunk) | |
| 17:50 | Tweaks to the new assert documentation. (check-in: 19d3bdb7e3 user: drh tags: trunk) | |
| 17:42 | Updates to the whyc.html and assert.html documentation pages. (check-in: e7ab215c5b user: drh tags: trunk) | |
Changes
Changes to pages/assert.in.
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 |
<p>The ALWAYS(X) and NEVER(X) macros are a weaker statement about the truth of X. The presence of ALWAYS(X) or NEVER(X) means that the developers believe X is always or never true, but there is no proof, or the proof is complex and error-prone, or the proof depends on other aspects of the system that seem likely to change. <p>In other systems, developers sometimes use assert(X) in a way that is similar to the use of ALWAYS(X) or NEVER(X) in SQLite. Developers will add an assert(X) as a [https://blog.regehr.org/archives/1576|tacit acknowledgement that they do not fully believe that X is always true]. We believe that this use of assert(X) is wrong and violates the intent and purpose of having assert(X) available in C in the first place. An assert(X) should not be seen as a safety-net or top-rope used to guard against mistakes. Nor is assert(X) appropriate for defense-in-depth. An ALWAYS(X) or NEVER(X) macro, or something similar, should be used in those cases because ALWAYS(X) or NEVER(X) will be followed by code to actually deal with the problem in the case where 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>The [https://golang.org|Go programming language] omits assert(). The Go developers [https://golang.org/doc/faq#assertions|recognize this is contentious]. |
| | |
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 |
<p>The ALWAYS(X) and NEVER(X) macros are a weaker statement about the
truth of X. The presence of ALWAYS(X) or NEVER(X) means that the developers
believe X is always or never true, but there is no proof, or the proof
is complex and error-prone, or the proof depends on other aspects
of the system that seem likely to change.
<p>In other systems sometimes use assert(X) in a way that is
similar to the use of ALWAYS(X) or NEVER(X) in SQLite.
Developers will add an assert(X) as a
[https://blog.regehr.org/archives/1576|tacit acknowledgement that they
do not fully believe that X is always true].
We believe that this use of assert(X) is wrong and violates the intent
and purpose of having assert(X) available in C in the first place.
An assert(X) should not be seen as a safety-net or top-rope used to
guard against mistakes. Nor is assert(X) appropriate for defense-in-depth.
An ALWAYS(X) or NEVER(X) macro, or something similar, should be used in
those cases because ALWAYS(X) or NEVER(X) will be followed by code to
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>The [https://golang.org|Go programming language] omits assert().
The Go developers
[https://golang.org/doc/faq#assertions|recognize this is contentious].
|