On Mon, Mar 23, 2015 at 3:41 PM, John Rose <[email protected]> wrote:
> > Eventually I think we'll have good enough library functions for range > checks that we can avoid working with explicit range check expressions. > Even experts get them wrong when subexpressions can overflow (for > subsequence range checks). > Guava has Precondtions: https://code.google.com/p/guava-libraries/wiki/PreconditionsExplained > For now, I would add one more tweak to Martin's: > > > if ((newPosition > limit) | (newPosition < 0)) > > throw positionOutOfBoundsException(newPosition); > > The instance creation expression and the string formatting are both cold > code which deserves to be segregated into a factory method. > > The throw itself is convenient to put into the caller code, though, > because (a) it doesn't increase caller bytecode complexity, and (b) it > doesn't confuse javac or the code maintainer with a nonexistent > fall-through of control after the error. > Many years ago I experimented with different variations. I see that this bug is still waiting for its day: JDK-6533165 <https://bugs.openjdk.java.net/browse/JDK-6533165> Failure to optimize methods that unconditionally throw
