This is a useful tangent. Assertions are definitely designed to be off in production, or else they serve no purpose. They are there to assert things that should never ever be false, if the program is working, no matter what bad input or network faults occur. Turning them off should have zero effect in a working program.
So they can't be for argument checking for instance or anything that could be true in an ugly world. If that's what they're being used for here I'd disagree with it -- it changes behavior. Those have to be "if" statements checking args. This is theory. In practice, I've always encountered the same general unease about running production differently than test. And it's justified. Who knows whether asserts were used correctly, per above? The tragic thing about asserts is that they are a perfectly useful construct, but because they are rarely used 100% correctly, must be left on, and then both defeat their own purpose (might as well be an "if") and worse, harm the program (overhead of checks that the programmer thought would be off) This is essentially why we don't use it in Mahout. At least it's the reason in my head. I don't like the "checked" and "unchecked" getter idiom. We have such a thing in Vector -- set() and setQuick(). From reading the API, well, who's not going to choose the quick operation over the "slow" one? If the caller has bothered to think about issues of bounds checking, why would the caller knowingly send bad input into the method that needs to be checked? So we end up with everyone using the unchecked method. (So what's the point of set() then?) In Vector, and maybe this new code too, the consequence of mis-using the unchecked version is I think tiny. Bad input will just result in an ArrayIndexOutOfBoundsException or NullPointerException quickly anyway. That's fine. It's less clean than explicitly checking and throwing a very proper exception, but, we don't really care about dealing with these situations cleanly, as long as the program correctness isn't compromised. So we probably get away with it just fine in Vector with setQuick(). But then... if this method has the speed and correctness properties everyone wants, why is there a separate set() method? On this line of reasoning, it's only feature is handling a very rare programmer error a little more cleanly. So it should just be the one set() method. So in this new annotation (which sounds great), I wonder if one can get away with leaning on the bounds checking and such that the JVM will do anyway. Everyone's happy then. It's fast and correct. However there may be times where not explicitly checking input will result in a real problem. You just can't avoid argument checking then. In cases where that vital argument checking is becoming a performance problem, I'd strongly suspect the better answer is to construct a method tailored to that use case. For example, often the answer is some kind of bulk-setter method. On Fri, Mar 25, 2011 at 8:29 PM, Ted Dunning <[email protected]> wrote: > That is why I prefer the default, even in production, to be to check. Not > checking should be the (very) special case where there are obscure reasons > to know that the access is correct that > the optimizer can't see. > > On Fri, Mar 25, 2011 at 12:17 PM, Dawid Weiss > <[email protected]>wrote: > > > The difference in speed may be marginal since newer hardware/hotspot will > > predict those branches almost never take place and probably discard them. > > >
