My intuition matches what Dan wrote above. Reproducing what I wrote in
Alexey's gerrit review yesterday:

I dislike Preconditions [for internal invariant checks] because the type of
exception thrown is "IllegalStateException" which is supposed to indicate
to a caller that they called a method at an inappropriate time. In my mind
it's meant to indicate "misuse" of an API, rather than
"mis-programming/bug" of an API (which an AssertionError more clearly

Again to make the comparison to our C++ style, we use CHECK/DCHECK for
cases where it would be an internal bug to see it fail, and "if (...)
return Status::IllegalArgument(...)" or whatever when it would just be
misuse of an API.
I like how Dan distinguished between "local context" and external usage of
a class. Taking a hypothetical example of a Stack implementation which
maintains its size as an internal integer, I would write something like:

Object pop() {
  // Use Preconditions here because the external user of the class should
not call pop()
  // on an empty stack, but the stack itself is internally consistent
  Preconditions.checkState(curSize > 0, "queue must not be empty");
  Object toReturn = data[--curSize];
  // Use an assert here because if we ended up with a negative size
counter, that indicates
  // that our stack implementation itself is broken - ie it's an invariant,
not a state check.
  assert curSize >= 0;
  return toReturn;

I see Alexey's point, though, that there are some checks that are worth
running even in "production" scenarios, because continuing on if the state
had gone bad would make no sense (or might result in wrong data results,
etc). In those cases I think an 'if (...) throw AssertionError()' could
make sense, and we could hypothetically wrap such a check in a helper class
like 'AlwaysAssert.assertTrue(...)' or whatever.

On Tue, Jul 11, 2017 at 1:24 PM, Dan Burkert <[EMAIL PROTECTED]> wrote:

Todd Lipcon
Software Engineer, Cloudera
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB