Just looked at this again. Using IOException causes problems, because the interface BinaryDecoder does not declare that as a possible exception.
How about using DecoderException instead? Seems just as appropriate to me. On 25/06/2008, Julius Davies <[EMAIL PROTECTED]> wrote: > +1 for IOException. > > I've come around on this. Originally I liked garbage-in, garbage-out > idea, but I'm +1 to IOException now. The reason I've come around is > that I just cannot imagine any Java developer who would be confused or > surprised when presented with an IOException in this situation. > > I'll open a ticket and attach a patch by Sunday if it hasn't been done > by then. It will need some JUnits, too. > > yours, > > Julius > > > > > On Wed, Jun 25, 2008 at 10:39 AM, Jochen Wiedmann > <[EMAIL PROTECTED]> wrote: > > On Sat, Jun 21, 2008 at 2:19 PM, sebb <[EMAIL PROTECTED]> wrote: > > > >> How should Base64.decode() handle invalid encoded data? > > > > I'd vote for an IOException. As the RFC indicates, such characters are > > more than likely indicators for errors. If anyone requires such a > > message, it is easy to implement a FilterInputStream, or FilterReader. > > > > Jochen > > > > > > -- > > Look, that's why there's rules, understand? So that you think before > > you break 'em. > > > > -- (Terry Pratchett, Thief of Time) > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > -- > yours, > > Julius Davies > 250-592-2284 (Home) > 250-893-4579 (Mobile) > http://juliusdavies.ca/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
