Asserts have their place as sanity checks. Just like exceptions have their 

They can both live in harmony and they both serve a purpose.

What doesn't serve a purpose is that comment encouraging n00b users to get a 
mythical 5% performance increase and then get silent corruption when their 
disk/io goes sideways and the asserts might have caught things before it went 
really wrong.

Sent from my iPhone

On Sep 21, 2016, at 10:31 AM, Edward Capriolo 
<<>> wrote:

" potential 5% performance win when you've corrupted all their data."
This is somewhat of my point. Why do assertions that sometimes are trapped
"protect my data" better then a checked exception?

On Wed, Sep 21, 2016 at 1:24 PM, Michael Kjellman <<>> wrote:

I hate that comment with a passion. Please please please please do
yourself a favor and *always* run with asserts on. `-ea` for life. In
practice I'd be surprised if you actually got a reliable 5% performance win
and I doubt your customers will care about a potential 5% performance win
when you've corrupted all their data.


On Sep 21, 2016, at 10:21 AM, Edward Capriolo 

There are a variety of assert usages in the Cassandra. You can find
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
they add?

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

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
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
All types of internal Util classes might throw it, downstream code is
essentially unaware and rarely specifically handles it. They do not
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