[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: InputHandler and end-of-stream

I missed this mail previously. Comments inline.

>> Hi

>> while reviewing some changes I realized DefaultInputHandler and
>> SecureInputHandler may create unexpected outcomes if 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.


To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxx