On 14/11/2013 23:27, Bill Shannon wrote:
:
I'd prefer that all variants of the API report the error in a way that allows
the users of the API to ignore the error, access the data that caused the error,
and supply replacement data if desired.
For most of the APIs, decoding as much data as possible and throwing an
exception with details about how much has been decoded and where the error
was detected would be best. I understand that designing this and getting
it right might exceed what you can do in this release. In that case, just
throw an exception with no details, and we can figure out what details to
provide later. Returning a negative number is kind of a hack, and unlike
most other APIs. Plus, if we decide we need to return two numbers (e.g.,
input and output positions), there's no way to extend it.
This is where the methods that decode buffers are useful as the input
and output buffer positions can be advanced to reflect the input that
had been decoded successfully. So even when strict then it should be
possible (although maybe ugly due to the exception) then you at least
know where the corruption starts and you have the bytes that have been
successfully decoded.
As regards adding API support for ignore or replace then I think this
will need to be something to consider for the future (it's just too late
for JDK 8).
-Alan.
