InputHandler and end-of-stream

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

InputHandler and end-of-stream

Stefan Bodewig
Hi

while reviewing some changes I realized DefaultInputHandler and
SecureInputHandler may create unexpected outcomes if System.in or
System.console() signal an end-of-stream and thus readLine/readPassword
return null.

The former will create an InputRequest with a null getInput() result
which may come unexpected, the later handler will cause an NPE. So far
this NPE would be swallowed (and still will be in 1.9.x) where
DefaultInputHandler is invoked as fallback, after my latest changes to
master it would bubble up, hence my question.

Should we add explicit null guards? I'm not really sure if/when such an
end-of-stream may occur. If so, what would be the outcome? Handle a null
input like an empty input and maybe fall back to the default value?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: InputHandler and end-of-stream

Jaikiran Pai
I missed this mail previously. Comments inline.

 >> Hi

 >> while reviewing some changes I realized DefaultInputHandler and
 >> SecureInputHandler may create unexpected outcomes if System.in or
 >> System.console() signal an end-of-stream and thus readLine/readPassword
 >> return null.

 >> The former will create an InputRequest with a null getInput() result
 >> which may come unexpected, the later handler will cause an NPE. So far
 >> this NPE would be swallowed (and still will be in 1.9.x) where
 >> DefaultInputHandler is invoked as fallback, after my latest changes to
 >> master it would bubble up, hence my question.

 >> Should we add explicit null guards?

I think we should.

 >>I'm not really sure if/when such an
 >> end-of-stream may occur. If so, what would be the outcome? Handle a null
 >> input like an empty input and maybe fall back to the default value?

Given that the null return value happens when the stream, from which we
are reading, has ended earlier than expected, IMO we should consider it
an error case and throw a more legible exception instead of falling back
to a default value or considering it an empty input.

-Jaikiran

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: InputHandler and end-of-stream

Stefan Bodewig
On 2018-06-03, Jaikiran Pai wrote:

> I missed this mail previously. Comments inline.

>>> Hi

>>> while reviewing some changes I realized DefaultInputHandler and
>>> SecureInputHandler may create unexpected outcomes if System.in or
>>> System.console() signal an end-of-stream and thus readLine/readPassword
>>> return null.

>>> The former will create an InputRequest with a null getInput() result
>>> which may come unexpected, the later handler will cause an NPE. So far
>>> this NPE would be swallowed (and still will be in 1.9.x) where
>>> DefaultInputHandler is invoked as fallback, after my latest changes to
>>> master it would bubble up, hence my question.

>>> Should we add explicit null guards?

> I think we should.

>>> I'm not really sure if/when such an
>>> end-of-stream may occur. If so, what would be the outcome? Handle a null
>>> input like an empty input and maybe fall back to the default value?

> Given that the null return value happens when the stream, from which
> we are reading, has ended earlier than expected, IMO we should
> consider it an error case and throw a more legible exception instead
> of falling back to a default value or considering it an empty input.

Sounds good, I'll make both handlers throw a BuildException in that
case.

Thanks

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]