Yeah, I understand what you're saying, don't get me wrong. However, I just spent close to a year total working and writing CASSANDRA-9754 and when you're dealing with IO, sometimes asserts are the right way to go. I found putting them there are sanity checks mostly to ensure that code changes to other parts of the code don't have unexpected interactions with the input bounds expected by a method. I think asserts are fine (and correct) in these cases.
> On Sep 21, 2016, at 11:16 AM, Edward Capriolo <edlinuxg...@gmail.com> wrote: > > 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. > > You have: > 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 > assert. > > 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 < > mkjell...@internalcircle.com> wrote: > >> Asserts have their place as sanity checks. Just like exceptions have their >> place. >> >> 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. >> >> best, >> kjellman >> >> On Sep 21, 2016, at 10:21 AM, Edward Capriolo <edlinuxg...@gmail.com >> <mailto:edlinuxg...@gmail.com>> >> wrote: >> >> There are a variety of assert usages in the Cassandra. You can find >> several >> tickets like mine. >> >> https://issues.apache.org/jira/browse/CASSANDRA-12643 >> >> https://issues.apache.org/jira/browse/CASSANDRA-11537 >> >> Just to prove that I am not the only one who runs into these: >> >> https://issues.apache.org/jira/browse/CASSANDRA-12484 >> >> 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%). >> -ea >> >> 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) >> >> http://stackoverflow.com/questions/2758224/what-does- >> the-java-assert-keyword-do-and-when-should-it-be-used >> >> "Assertions >> <http://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.10> >> (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." >> >> http://stackoverflow.com/questions/1957645/when-to-use- >> an-assertion-and-when-to-use-an-exception >> >> "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? >> >> >>
