Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream (original) (raw)
Chris Hegarty chris.hegarty at oracle.com
Fri Feb 1 14:48:21 UTC 2013
- Previous message: Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream
- Next message: Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message: Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream
- Next message: Codereview request for 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]