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: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
