Hello,
> 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).
This is not correct. This exception is thrown when a string token from
the input stream exceeds the maximum string token length. (The maximum
length is used to prevent invalid/malicious input from allocating an
enormous string in the JVM.) So, the error is with the input, not the
caller.
The general principle with the geometry IO code is that IOExceptions
(which the methods in question must already declare since they
ultimately read from InputStreams) indicate an error extracting data
from the input. Possible cases include:
- network/file system errors
- parsing/syntax errors
- data conversion errors (e.g. string to double)
Runtime exceptions may be thrown for other issues occurring after the
raw data has been retrieved from the file/stream, primarily if the
extracted data is not mathematically valid.
I feel that this separation of exception behavior between IO/format
errors and high-level mathematical validation is useful. As an end
user of an application that uses this library, I want to know if the
file I provided was just plain invalid versus if it just contained a
wonky geometry.
Regards,
Matt
On Sat, Jul 24, 2021 at 8:28 AM Gilles Sadowski <gillese...@gmail.com> wrote:
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
