You are essentially arguing, "if you turn off -ea your screwed" which is a
symptom of a larger problem that I am pointing out.
Forget the "5%" thing. I am having a discussion about use of assert.
1) checked exceptions
2) unchecked exceptions
3) Error (like ioError which we sometime have to track)
The common case for assert is to only be used in testing. This is why -ea
is off by default.
My point is that using assert as a Apache Cassandra specific "psuedo
exception" seems problematic. I can point at tickets in the Cassandra Jira
where the this is not trapped properly. It appears to me that having deal
with a 4th "pseudo exception" is code smell.
Sometimes you see assert in place of a bounds check or a null check that
you would never want to turn off. Other times it is uses as a quasi
IllegalStateException. Other times an class named "estimator" asserts when
the "estimate" "overflows". This seem far away from the defined purpose of
The glaring issue is that it bubbles through try catch so it hardly makes
me feel "safe" either on or off.
On Wed, Sep 21, 2016 at 1:34 PM, Michael Kjellman <
> 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 <edlinuxg...@gmail.com
> <mailto:edlinuxg...@gmail.com>> 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 <
> mkjell...@internalcircle.com<mailto:mkjell...@internalcircle.com>> 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 <edlinuxg...@gmail.com
> 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 jvm.properties 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?