[anishmehta24]

The String peer passes the program's indices straight to the host String, so an out-of-range index throws in the host JVM, and NativeMethodInfo turns that into a JPFNativePeerException that stops the search. For example

"abc".substring(2, 1);

throws StringIndexOutOfBoundsException on a normal JVM, but under JPF it ends with exception in native method java.lang.String.substring. A catch in the program never runs, and an uncaught one is not reported as a NoUncaughtExceptionsProperty violation.

The same happens for charAt, codePointAt, codePointBefore, codePointCount, offsetByCodePoints, getChars, getBytes(int, int, byte[], int), both substrings and the String(char[]/int[]/byte[], offset, count) constructors, plus an unknown charset name in String(byte[], int, int, String). These now catch the exception and throw it in the program with env.throwException, the way getBytes(String) already does. checkBoundsOffCount threw a host exception directly; it now throws in the program too.

Tested on Windows 11 with Temurin 11.0.32: the two new StringTest cases fail on master and pass with this change. Full ./gradlew test: 1048 passed, and the only failures are the two URLClassLoaderTest cases that also fail on Windows on master (#427, fixed in #644).