I don't have a preference for checked or unchecked exceptions. I just
want it to be consistent, easy to use, and maintainable. With that
said, what specific changes are you picturing should be made to the
code here? Are you suggesting a geometry-specific exception type?
Should we wrap IOExceptions as runtime exceptions?
-Matt
On Sat, Jul 24, 2021 at 12:11 PM Gilles Sadowski <gillese...@gmail.com> wrote:
>
> Hi.
>
> Le sam. 24 juil. 2021 à 17:01, Matt Juntunen
> <matt.a.juntu...@gmail.com> a écrit :
> >
> > 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.
>
> There is a misunderstanding; in my statements, "caller" and "input" are
> used interchangeably, and synonyms for "precondition violation", IOW:
> "This method assumes <this> and <that>, and if you call it by passing
> input that is not compliant, it will throw an exception".
> In the above sentence, a _runtime_ exception is thrown if the error
> is not recoverable.
>
> Note that "recoverable" would imply that the caller (*within* [Geometry])
> catches the (checked) exception and is able to complete the requested
> task. [I don't know how that's possible in this instance (where input has
> been identified as wrong).]
>
> > 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)
>
> None of those are recoverable from the POV the [Geometry] code:
> Parsing having failed for any of those reason will raise an exception
> and it's up to the caller to sort it
> There is no added value for this exception to be checked by the
> compiler.
> Going against currently recommended practice (cf. e.g. "Effective
> Java" by J. Bloch) would only be valid for BC reasons (cf. recent
> discussion about [Compress]).
>
> > 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.
>
> Example (b) does the opposite: It turns a runtime exception into an
> "IOException".
>
> I note that parsing occurs _after_ reading; such that any "IOException"
> that is raised from an underlying stream should (IMO) be caught ASAP
> and wrapped in a runtime exception (to be rethrown, since the condition
> is not recoverable).
> The root cause (e.g. whether it is a parse issue or a file system issue)
> will be visible in the stack trace. No need to spread "throws" clauses
> for that.
>
> > I feel that this separation of exception behavior between IO/format
> > errors and high-level mathematical validation is useful.
>
> I agree, but "different behaviours" can be implemented by different
> types. This is orthogonal to "checked" vs "unchecked".
>
> > 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.
>
> I'm not sure I understand the issue (it seems to me that both are
> irrecoverable). Please provide an example that mandates checked
> exceptions.
>
> Regards,
> Gilles
>
> >
> > 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
> >
>
> ---------------------------------------------------------------------
> 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
