Alan Bateman wrote on 11/15/13 04:21: > 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.
And hopefully the same for the stream-based version. > 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). Right, as long as I can wrap the strict API to provide this effect, that's good enough for now.
