I believe the testimony is that the code is executed 2600 times at
startup.
But Rangecheck is sanity check code. I will provide a faulty
analogy. Let's think of Rangecheck as a lifeguard at a pool. Every time a
swimmer
wants to go into the water, even if they just go out, the lifeguard
verifies that
there is water in the pool. If
not, all swimmers are sent home
and the pool is shut down for the day. One
fault with that analogy is that the
callers of Rangecheck have their own pools.
What is an array? It's a
block of contiguous memory reserved for
homogeneous data
and featuring instant
access and update. For example, it behaves better than a
list, which takes n
steps to get to or update the n+1st element. A list, though,
cannot be filled
past its end, where an array is set up with a fixed number of
slots. If you
need 20 slots, but the array was initialized with 15, one has to start
a new
array, copy the 15 elements, initialize the other 5, and then notify the
program that the new 20-slot array is what is now current. (The old array has
its
memory freed.) Here's a bit of history. In C and C++ programming, if one
called
an
index beyond the end of an array, the contents of that memory would
be
dereferenced, read and processed,
even though it had no validity as a
member of the array. The program crashes, or
more insidiously, produces invalid
answers. Java specifies that an
Exception be thrown when the value of a
non-existent index is requested from
an
array. This is a RuntimeException,
which means the program stops.
During development and debugging, indices
that don't exist
are common exceptions and occur because there are logic
problems as the
algorithm and implementation evolve. Developers see the
Exception, figure out
why they wanted value 17 from a 16
item array and fix
that
logic error. Shipping code should not have
ArrayIndexOutOfBoundsExceptions,
but Rangecheck cannot know that the code is
solid, so it does its job each and
every time someone wants a value from an
array. Is it necessary to the
program? Well, it's an implementation of
the java specification regarding the
behavior of arrays. But good programs
don't need it and, indeed, it exacts a cost
in time as the lifeguard keeps
checking that the pool has water. [ Reply to This | Parent | # ]
|
It's executed fairly often. But rangeCheck() won't have a significant effect
on the program's operation. If the program's fully debugged rangeCheck() won't
ever find a problem and will just return, and to the user the program will
behave exactly as if rangeCheck() weren't called at all. If there's a bug and
rangeCheck() finds a problem, it throws an exception that'll probably cause the
program to crash. But the problem would've caused the program to crash anyway if
rangeCheck() hadn't detected it, and to a user the subtle variation in the exact
crash won't make any difference, the program's still
crashed.
rangeCheck(), as often as it's called, simply makes no
difference to the operation of the program that a user could see. [ Reply to This | Parent | # ]
|
