Errors Chapter

[dabrahams]

No description provided.

[camio]

Suggested change

	What we present here is not the only logically consistent approach to
	errors, and our approach may clash with your instincts. It is the
	result of optimizing for local reasoning and the ergonomics of
	scalable software development, and the justifications for our choices
	are interdependent. We hope you'll bear with us as we tie them all
	together.

It goes without saying that there are other logically consistent approaches to errors and the book's focus on ergonomics of scalable software development should be covered in the introduction. I sum, I don't see much value in this paragraph.

[dabrahams]

I am skeptical of its value also.

[camio]

I don't think the "avoidable" qualification adds anything. Additionally, I fixed the tense of the examples to match

Suggested change

	> - **Programming Error**, or **bug**: code contains an
	> avoidable[^avoidable] mistake. For example, an `if` statement
	> tests the logical inverse of the correct condition.
	>
	> - **Runtime error**: a function could not fulfill its postconditions
	> even though its preconditions were satisfied. For example,
	> writing a file might fail because the filesystem is full.
	[^avoidable]: While bugs in general are inevitable, every *specific*
	bug is avoidable.
	> - **Programming Error**, or **bug**: code contains a
	> mistake. For example, an `if` statement
	> testing the logical inverse of the correct condition is a bug.
	>
	> - **Runtime error**: a function could not fulfill its postconditions
	> even though its preconditions were satisfied. For example,
	> writing a file might fail because the filesystem is full.

[dabrahams]

I'm not sure what I had in mind when I wrote that. It's not like me to use a term (and footnote it!) without having some meaning in mind. I think maybe I meant to say that runtime errors are not avoidable.