Found while working on JDK-8369699.
We use different exception names for "out of bounds" cases:
jshell> VectorShuffle.iota(IntVector.SPECIES_128, 0, 1, true).laneSource(100)
| Exception java.lang.IllegalArgumentException: Index 100 must be zero or positive, and less than 4
| at Int128Vector.lane (Int128Vector.java:525)
| at Int128Vector$Int128Shuffle.laneSource (Int128Vector.java:854)
| at (#6:1)
jshell> VectorMask.fromLong(IntVector.SPECIES_512, 0xff).laneIsSet(100)
| Exception java.lang.IndexOutOfBoundsException: Index 100 out of bounds for length 16
| at Preconditions.outOfBounds (Preconditions.java:100)
| at Preconditions.outOfBoundsCheckIndex (Preconditions.java:106)
| at Preconditions.checkIndex (Preconditions.java:302)
| at Objects.checkIndex (Objects.java:365)
| at Int512Vector$Int512Mask.laneIsSet (Int512Vector.java:785)
| at (#7:1)
jshell> IntVector.zero(IntVector.SPECIES_128).lane(100)
| Exception java.lang.IllegalArgumentException: Index 100 must be zero or positive, and less than 4
| at Int128Vector.lane (Int128Vector.java:525)
| at (#10:1)
The 3 cases above are all about lane-access, but we use both:
- IllegalArgumentException
- IndexOutOfBoundsException
And then for cases like convertShape "part", we even use:
- ArrayIndexOutOfBoundsException
part = -10 exception: java.lang.ArrayIndexOutOfBoundsException: bad part number -10 converting Species[float, 2, S_64_BIT] -> Species[double, 8, S_512_BIT] (lanes are expanding by 2)
This seems a bit odd. We should strive for consistency here, unless there is a good reason.
We should probably use "IndexOutOfBoundsException" for all cases. Using "Array..." probably won't make much sense if we eventually go away from using arrays in the implementation ... and anyway: the user does not need to know that we use arrays.
This is not a comprehensive survey, I just noticed that we use different exceptions. A part of this task is to generally make the use of exceptions consistent.
We use different exception names for "out of bounds" cases:
jshell> VectorShuffle.iota(IntVector.SPECIES_128, 0, 1, true).laneSource(100)
| Exception java.lang.IllegalArgumentException: Index 100 must be zero or positive, and less than 4
| at Int128Vector.lane (Int128Vector.java:525)
| at Int128Vector$Int128Shuffle.laneSource (Int128Vector.java:854)
| at (#6:1)
jshell> VectorMask.fromLong(IntVector.SPECIES_512, 0xff).laneIsSet(100)
| Exception java.lang.IndexOutOfBoundsException: Index 100 out of bounds for length 16
| at Preconditions.outOfBounds (Preconditions.java:100)
| at Preconditions.outOfBoundsCheckIndex (Preconditions.java:106)
| at Preconditions.checkIndex (Preconditions.java:302)
| at Objects.checkIndex (Objects.java:365)
| at Int512Vector$Int512Mask.laneIsSet (Int512Vector.java:785)
| at (#7:1)
jshell> IntVector.zero(IntVector.SPECIES_128).lane(100)
| Exception java.lang.IllegalArgumentException: Index 100 must be zero or positive, and less than 4
| at Int128Vector.lane (Int128Vector.java:525)
| at (#10:1)
The 3 cases above are all about lane-access, but we use both:
- IllegalArgumentException
- IndexOutOfBoundsException
And then for cases like convertShape "part", we even use:
- ArrayIndexOutOfBoundsException
part = -10 exception: java.lang.ArrayIndexOutOfBoundsException: bad part number -10 converting Species[float, 2, S_64_BIT] -> Species[double, 8, S_512_BIT] (lanes are expanding by 2)
This seems a bit odd. We should strive for consistency here, unless there is a good reason.
We should probably use "IndexOutOfBoundsException" for all cases. Using "Array..." probably won't make much sense if we eventually go away from using arrays in the implementation ... and anyway: the user does not need to know that we use arrays.
This is not a comprehensive survey, I just noticed that we use different exceptions. A part of this task is to generally make the use of exceptions consistent.
- relates to
-
JDK-8369699 Template Framework Library: add VectorAPI types and operations
-
- Open
-