> It seems like your experiences confirm my own. People toy with the idea of turning off sanity checks in production, but eventually reality sets in and they realize that this is a bad idea. Then they keep calling the sanity checks "assertions," because nobody wants to submit a search-and-replace patch for a big code base, and a few die-hards still cling to the dream of running without error checking.
No. They don't. Practically nobody runs Postgres or the product we shipped with assertions on (it would be too expensive, and requires recompiling besides), and the only reason people run with assertions on in Python is because it's the easiest way to do things (the default), whereas in most C programs the default is to not have the assertions. However, I note that people don't seem to use assertions as crutch in Python in spite of them being on, because I very seldom see an assertion error crop up in production. When they do, I know the program has gone completely haywire and is no longer internally consistent rather than merely encountering an error it couldn't handle, and report the bug as such. This is very rare; practically, they could be turned off.
However, I get reasonable number of assertion violations when trying to change software while in development or while reading the source, and that's where I find them very useful.
I do reserve a special annoyance for slick assertions that are inadequately explained via comment.
So far we've established that:
1. you run with assertions always on in production,
2. you have encountered errors caught by the always-on assertions in production (it may be "seldom," but then all errors are seldom, hopefully.)
How does this not prove my point? Turning off error checking is stupid. Your software will never be bug-free. Start dealing with reality and rename your assertions to sanity checks, which is what they are and always have been.
> So far we've established that: 1. you run with assertions always on in production, 2. you have encountered errors caught by the always-on assertions in production
No. I gave two examples, one where assertions are run in production (mostly because it's easier) and I'm trying to communicate with you that I don't see people leaning on assertions to find bugs in production code very frequently at all, and this is the fear of the Go FAQ. I gave another example were assertions are invariably not compiled into the program when running in production. Am I not being clear about this?
> (it may be "seldom," but then all errors are seldom, hopefully.)
False. Errors (like "no permission to file", "out of disk", "out of memory") are distinct from 'an internal consistency check has failed.'
These happen all the time for completely legitimate reasons.
> Turning off error checking is stupid. Your software will never be bug-free. Start dealing with reality and rename your assertions to sanity checks, which is what they are and always have been.
Strong words. Okay, here's what I think is stupid:
* Software too slow for the purpose.
* Avoiding writing expensive invariants because it would make the software too slow.
* The notational similarity of a broken invariant that intended to never occur vs. an error condition.
My solution has been to accept the last-most option and to stop writing expensive invariants, even though I wish I could succinctly and idiomatically communicate to all maintainers that the invariant is considered impossible rather than merely an error condition and run with the expensive invariants while in development (a global variable and praying to the branch prediction gods can be close enough).
Needing lots of expensive invariants is almost "invariably" (see what I did there?) a code smell. You often see big, complex classes with 10 different booleans and a ton of assertion crap, when what is really needed is to refactor the class into smaller classes which are unit-testable. In C++, I've even seen people assert that an unsigned integer was >= 0. You can just feel the quality.
The notational similarity of a broken invariant that intended to never occur vs. an error condition.
Go has a notation for problems that are never supposed to happen: panic. For other errors, there are return codes.
> Needing lots of expensive invariants is almost "invariably" (see what I did there?) a code smell.
What's your definition of need? I want a lot of invariants if because I have found it reduces the chance of error. This is also the finding in that Microsoft case study I linked to. The more invariants, the better, and that means making them cheap to write.
> In C++, I've even seen people assert that an unsigned integer was >= 0. You can just feel the quality.
Entirely reasonable in some cases; it's telling me: "this software is not defined for negative numbers". There does exist code that can accept an unsigned number (because it is what callers found most convenient at the time, and casting is wordy) but is defined on negative inputs, and it would not be valid to put that assertion there. Those assertions are to assist future collaborators of your software, and shorter to write than:
// This algorithm is only defined on positive integers
Until one is using a language with real dependent types, I think your specific example is not on the face of it as egregious as you say it is.
> Go has a notation for problems that are never supposed to happen: panic. For other errors, there are return codes.
Unfortunately I do see panic used -- even in the standard library -- as a flow control mechanism also. But yes, I do use panic for this reason, and tend to eschew using recover for convenience in most situations. It is the lack of an idiom to obtain complete clarity as to the nature of the panic that I find mildly irritating.
OK, my response was maybe a little more snarky than I intended. Anyway, I think we are going to have to agree to disagree about the utility of turn off error checking in production.
No. They don't. Practically nobody runs Postgres or the product we shipped with assertions on (it would be too expensive, and requires recompiling besides), and the only reason people run with assertions on in Python is because it's the easiest way to do things (the default), whereas in most C programs the default is to not have the assertions. However, I note that people don't seem to use assertions as crutch in Python in spite of them being on, because I very seldom see an assertion error crop up in production. When they do, I know the program has gone completely haywire and is no longer internally consistent rather than merely encountering an error it couldn't handle, and report the bug as such. This is very rare; practically, they could be turned off.
However, I get reasonable number of assertion violations when trying to change software while in development or while reading the source, and that's where I find them very useful.
I do reserve a special annoyance for slick assertions that are inadequately explained via comment.