Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream
pdoubleya at gmail.com
Fri Feb 1 10:14:22 UTC 2013
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
On Fri, Feb 1, 2013 at 10:43 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:
> On 31/01/2013 23:20, Xueming Shen wrote:
>> Any opinion of an ioe based specific InvalidedBase64BytesException
>> is more appropriate/preferred/desired in this kinda of situation? The
>> argument against the IAE is probably that an IAE may be a surprise
>> for someone working on inputstream.read().
> I just replied to your original mail, as IAE doesn't make sense here.
> I guess the question on whether you need a specialized exception comes
> down to whether it would be useful to take recovery action that would be
> different to other I/O exceptions that might happen. If we don't have good
> use-cases then it's probably not worth doing it now, it is always something
> that could be added later if really needed (as it shouldn't break anyone to
> throw a more specific exception in the future).
More information about the core-libs-dev