Note that the JRE provides UncheckedIOException. Gary
On Sat, Jul 24, 2021, 12:25 Matt Juntunen <matt.a.juntu...@gmail.com> wrote: > 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 > >