Hello.
Somehow I missed that [Geometry] contains usage of checked exceptions.
As mentioned in other threads, I have a hard time conceiving that the kind
of codes we are dealing with here ever needs the concept of checked
exception (in its intended usage per the _current_ Java experts, and not
based on outdated practice from the time when Java advocates were hoping
that checked exceptions would be the cure to all evil...).
Examples:
(a)
---CUT---
/** Get the string collected by this instance.
* @return the string collected by this instance
* @throws IOException if the string exceeds the maximum
configured length
*/
public String getString() throws IOException {
if (hasExceededMaxStringLength()) {
throw parseError(line, col, STRING_LENGTH_ERR_MSG +
maxStringLength);
}
return sb.toString();
}
---CUT---
AFAICT, a precondition (max string length) is violated by the input: the
error is the caller's fault (either passing a too long string, or not having
set an appropriate upper bound). In any case, it is not recoverable, so
a checked exception is ruled out.
(b)
---CUT---
/** Get the current token parsed as an integer.
* @return the current token parsed as an integer
* @throws IllegalStateException if no token has been read
* @throws IOException if the current token cannot be parsed as an integer
*/
public int getCurrentTokenAsInt() throws IOException {
ensureHasSetToken();
Throwable cause = null;
if (currentToken != null) {
try {
return Integer.parseInt(currentToken);
} catch (NumberFormatException exc) {
cause = exc;
}
}
throw unexpectedToken("integer", cause);
}
---CUT---
"Integer.parseInt" (JDK) complies with the rationale: a runtime exception
is rightfully thrown on precondition failure (input cannot be parsed as an
"integer"), and turning it into a checked exception just adds complexity
for zero gain (such errors are all the same non-recoverable).
For the parser to be robust (in the sense of not crashing the code without a
message that correctly identifies the cause of the failure), there is no need
for checked exceptions.
IMO, for any new code, the introduction of a checked exception should be
accompanied by an example demonstrating what the library does in order
to _recover_. [If it doesn't to anything (other than throw, rethrow, or log an
error message) then an unchecked exception should be used instead.]
Regads,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
