> 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.
This is an interesting point of view and I think I like it even better than my own, only I would change "zero effect in a working program" to "zero effect in a correctly written program". That is adhering to API contracts, etc. This was actually my understanding when I was writing HPPC -- that once your code passes a million unit/ integration tests you can trust it enough to run it without assertions in production... when/if something breaks, you will know anyway because of malformed output or other exceptions and then you can rerun with assertions on or add more tests. I guess both viewpoints have pros and cons, so convincing anybody does not make much sense, but it's an interesting discussion nonetheless. > 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? Exactly. I always found it a bit odd when I was presented two versions of essentially the same method... and usually went with the "riskier" one. > unchecked version is I think tiny. Bad input will just result in an > ArrayIndexOutOfBoundsException or NullPointerException quickly anyway. It may or it may not, if your storage is larger than your input. I guess most of the problems are off-by-one errors and not off-by-million (or negative index) errors. > 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. Not really because it's a flat array underneath so offsets are a cumulative product of indexes and you can get a wrong/different result while still being in-bounds of the storage array. I think a nice addition would be to allow specifying if you want to have ifs or assertions (it's generated code anyway) so that people can pick what they are comfortable with. I'll add it to the TODO list -- thanks for inspiration, Sean. Dawid
