>This method converts a byte array into a sequences of characters,
>which is then returned as a new instance of String. There's a problem
>though. If the byte array cannot be converted (wrong number of
>bytes/many other reasons) to chars, then the converter will throw a
>CharConversionException. This is the right thing to do. However,
>String(byte[], encoding) is not allowed to throw a
>CharConversionExecption.
BTW: In my gnu.java.io.EncodingManager classes there are static methods that
return a Decoder object that will convert a byte array for you in one easy
call. For the purposes of String and other classes that don't actually need
to read from an underlying stream, and thus don't need to maintain any
instance state, I cache Decoder instances for faster lookup. (There was a
bug in the bug parade on how slow the JDK String class converted bytes,
which was partially due to looking up and creating a new instance of the
converter class every time). If you are using the default encoding, it
should be very fast as I keep a reference to that cached object in an
instance variable. This is only used if you call the form of the method
that is meant to get the default encoding. If you grab the name of the
encoding and specify it manually, then you will use the slower hash table
lookup.
I've got some encoding work left to do, but I don't plan any API changed
right now. I plan on taking care of them right after I get done testing
StreamTokenizer, which is coded and compiles.
As to your problem, the default encoding scheme is ASCII. You could, if all
other conversion fails, simply truncate all chars to the low 7 or 8 bits,
which is what the JDK does in several cases in java.io. You won't be able
to use my ASCII converter because at your request I am making it throw
exceptions if it encounters an out of range character.
>On a side note, I'm getting very tired of all these "bugs" in the Java
>API. Almost every single method of Sun's java.lang.Character has some
>type of bug, and I really don't feel like submitting 20+ bug reports.
Welcome to the club. While it is not applicable to this case, when I come
across big problems with no declared exception, I just throw an Error or
something similar that does not need to be declared. Of course this kills
the application so is only appropriate in certain circumstances.
--
*****************************************************
* Aaron M. Renn *
* Email: [EMAIL PROTECTED] *
* Homepage: <URL:http://www.urbanophile.com/arenn/> *
*****************************************************
