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