InputHandler and end-of-stream

classic Classic list List threaded Threaded
1 message 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]