-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve AutoContinuingInputStream failure case #429
Improve AutoContinuingInputStream failure case #429
Conversation
…plicate the fatal exception
…but don't be stupid about adding an exception to itself
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
bytesRead, | ||
ex); | ||
ex.getMessage()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any possibility of ex
being null?
} catch (final IOException ce) { | ||
originalIOException.addSuppressed(ce); | ||
super.continueWith(this.continuator.buildContinuation(originalIOException, this.getBytesRead())); | ||
} catch (final IOException ioe) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be paranoid, but you may want to catch UncheckedIOException
as well.
Currently if an unrecoverable exception happens while using try-with-resources in combination with auto-resume the following will occur:
AutoContinuingInputStream
will catch it and invokeattemptRecovery
to ask its continuator for a continuationContinuingInputStream
will callthis.discardWrapped()
which closes the wrapped stream and setsthis.wrapped
tonull
attemptRecovery
will attempt to add the newly caught exception as a suppressed exception of the original (thinking it was related to recovery)AutoContinuingInputStream
callsthis.getWrapped().close()
(because the superclass already discarded the wrapped stream so there is nothing to close) so that NPE is attached to the original exception as a suppressed exceptionThis is all much more complicated than it needs to be and is the result of over-eager behavior on the part of
ContinuingInputStream
and a missing null check inAutoContinuingInputStream#close
. The resulting exception looks like this:Instead, we'd rather just throw
javax.net.ssl.SSLException: SSL peer shut down incorrectly
and call it a day. This PR fixes that situation and adds a test for verifying that an exception rethrown byInputStreamContinuator#buildContinuation
is rethrown as-is.This PR also makes
ContinuingInputStream
easier to use by removing the automatic calls todiscardWrapped()
on any exception so some redundanttry
statements have also been removed.