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()?
Alternatively, perhaps throwing an IOException with an embedded
Base64Encoding/DecodingException could also be used ?
The exception message is detailed/useful already, it's just whether this
needs a specialized IOException or an appropriate cause. If there are
good reasons to recover differently to other I/O exceptions then it may
make sense. The other useful thing about a specialized exception is that
it could carry more context, like the line or position where the stream
is corrupted.
-Alan.
