Thanks Alan, Chris and Ulf for the review and comments. The wording
has been updated accordingly. Hope it is clear enough for push.
http://cr.openjdk.java.net/~sherman/8006295_8006315_8006530/webrev/
-Sherman
On 02/04/2013 08:36 AM, Ulf Zibis wrote:
Am 04.02.2013 17:05, schrieb Chris Hegarty:
On 04/02/2013 14:20, Alan Bateman wrote:
On 01/02/2013 16:55, Xueming Shen wrote:
Hi,
For 8006295 it appears the more reasonable approach is to continue
throw IOE
but document this behavior clearly at the wrap(is) API. So the change
is joined
with these two.
8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream
which throws unspecified IOException on attempt to decode invalid
Base64 byte stream
http://cr.openjdk.java.net/~sherman/8006295_8006315_8006530/webrev/
Thanks!
-Sherman
In Decoder's javadoc then I would suggest "as if followed by padding
characters(s)" rather than "as if there are padding charcacter(s)
followed".
In wrap's javadoc it currently reads:
"If the input byte stream is not in valid Base64 encoding scheme then
IOException will be thrown when reading any invalid Base64 byte(s) from
the returned input stream."
I most like this, but adding some {@code ...} tags would help, at least for IOE. Maybe
one of the terms "Base64" would be enough, like:
If the input byte stream is not of valid Base64 encoding scheme then {@code
IOException} will be thrown by it's {@code read} methods when encountering any
undecodable byte(s)
I guess this okay but an alternative would be:
"The {@code InputStream} methods that reads from the stream throw {@code
IOException} if bytes are read that cannot be decoded".
Better: ... that read ... (no 's', typo ?)
Also: ... byte(s) ...
OR
"The {@code read} methods of the returned {@code InputStream} will throw {@code
IOException} if it encounters bytes that cannot be decoded".
My 2 ct:
... encounters any Base64-invalid byte(s)
-Ulf
