Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Some days ago I realized that PrintWriter (as well as PrintStream) never throw an IOException when writing, flushing or closing.
Instead it sets an internal flag (trouble=true) when an error occurs.
It’s not possible to get the exact exception, but only if there was some exception (checkError()).
My question is: why would one want to have such behavior? Isn’t that bad API design?
I think that since
System.outandSystem.errare instances ofPrintStream, some more relaxed error handling was provided. This was probably, as other posters have mentioned, to smooth the way for those transitioning from C/C++ circa 1995. When the Reader/Writer API was added,PrintWriterwas created to parallel the existingPrintStream.One application where this behavior is extremely desirable is logging. Logging is ancillary to a larger application. Typically, if logging fails, one doesn’t want that the entire application to fail. Thus, it makes sense for
System.err, at least, to ignore exceptions.