> This is only a one-time thing however, once a programmer learns about > encodings and the default being utf8 they're not likely to make that > mistake again. Also I believe you mentioned that the probability of > random binary data decoding as valid utf8 is low; so chances are they'll > get an exception too. If the exception is more clear and says "UTF8 > decoding failed" instead of "decode-error" like it does now, and if the > :help message for that exception mentions that you can change the > encoding, the chances of long-term confusion are minimal.
This is no longer the case wrt throwing exceptions; for most applications, it's more useful to put a replacement character in the string when decoding than to throw an exception. I was planning on implementing something so you could do "pathname" utf8 strict <file-reader> to thrown an exception rather than pushing U+FFFD. But this should not be the default, because it can lead to really stupid errors like this one: http://www.logilab.org/embed?url=http%3A//www.logilab.org/cgi-bin/hgwebdir.cgi/xmldiff/diff/e70c25f0eb08/debian/changelog Here, an ascii decoding was used, and it threw an exception because the file was apparently in UTF-8. A better action to take in most cases is to display replacement characters. At least the user gets *something*. It's even more useful in the case of a slightly corrupted UTF-8 stream, something UTF-8 was designed to handle gracefully. (That wasn't meant as an argument one way or the other on encoding APIs) Dan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
