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()?
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.
