There are a variety of assert usages in the Cassandra. You can find several
tickets like mine.

Just to prove that I am not the only one who runs into these:

To paraphrase another ticket that I read today and can not find,
"The problem is X throws Assertion which is not caught by the Exception
handler and it bubbles over and creates a thread death."

The file claims this:

# enable assertions.  disabling this in production will give a modest
# performance benefit (around 5%).

If assertions incur a "5% penalty" but are not always trapped what value do
they add?

These are common sentiments about how assert should be used: (not trying to
make this a this is what the internet says type debate)

<> (by
way of the *assert* keyword) were added in Java 1.4. They are used to
verify the correctness of an invariant in the code. They should never be
triggered in production code, and are indicative of a bug or misuse of a
code path. They can be activated at run-time by way of the -eaoption on the
java command, but are not turned on by default."

"An assertion would stop the program from running, but an exception would
let the program continue running."

I look at how Cassandra uses assert and how it manifests in how the code
operates in production. Assert is something like semi-unchecked exception.
All types of internal Util classes might throw it, downstream code is
essentially unaware and rarely specifically handles it. They do not always
result in the hard death one would expect from an assert.

I know this is a ballpark type figure, but would "5% performance penalty"
be in the ballpark of a checked exception? Being that they tend to bubble
through things uncaught do they do more danger than good?

Reply via email to