You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2018/04/11 07:46:19 UTC
InputHandler and end-of-stream
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: InputHandler and end-of-stream
Posted by Stefan Bodewig <bo...@apache.org>.
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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: InputHandler and end-of-stream
Posted by Jaikiran Pai <ja...@gmail.com>.
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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org