Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream

[Chris Hegarty]

On 01/02/2013 14:35, Mark Sheppard wrote:
>
> Hi Alan,
>
> I think it would be useful to convey some additional information
> relating the cause of the problem, even for diagnostic purposes.
>
> So analogous to CharacterEncodingException which exists for Charsets,
> providing a Base64EncodingException
> and Baes64DecodingException as derived from IOException, (as alluded to
> previously by Sherman,) could/would be useful.
> However, as the underlying encapsulating InputStream/FilterOutputStream
> is no exposed, and hence the overridden
> read/write methods publicly defined, how would such exceptions be
> reconciled against the generalized Output/InputStream returned by wrap()?

It could simply be in the method description for warp, but I think as 
Alan said, there doesn't seem to be a clear need for such a public 
exception type.

-Chris

>
> Alternatively, perhaps throwing an IOException with an embedded
> Base64Encoding/DecodingException could also be used ?
>
> regards
> Mark
>
> On 01/02/2013 11:40, Alan Bateman wrote:
>> On 01/02/2013 10:14, Patrick Wright wrote:
>>> Would it be appropriate to have a "format" exception extending
>>> RuntimeException? That could then be documented in the API, but
>>> optional to catch explicitly. "Format exceptions", as a name, are
>>> already used for converting numbers and dates, for example. It could
>>> be "upgraded" to a checked exception in a later release, it people
>>> found it useful. A nice thing about a format exception is you could
>>> (possibly) include more detail about where the conversion failed, and
>>> why, via fields/getters on the exception.
>> This is an InputStream and so will be used with libraries and code
>> that will rightly expect it to behave as an InputStream. So I think it
>> would be better to keep it as an IOException (whether a specialized
>> IOException is needed is debatable). That would be consistent with how
>> we handle malformed and unmappable input in other areas.
>>
>> -Alan.
>>