all corruption systematically ignored but data piece logged in for analysis
Abdur-Rahmaan Janhangeer, Mauritius abdurrahmaanjanhangeer.wordpress.com On 17 Oct 2017 21:43, "Israel Brewster" <isr...@ravnalaska.net> wrote: > I have written and maintain a PEP 249 compliant (hopefully) DB API for the > 4D database, and I've run into a situation where corrupted string data from > the database can cause the module to error out. Specifically, when decoding > the string, I get a "UnicodeDecodeError: 'utf-16-le' codec can't decode > bytes in position 86-87: illegal UTF-16 surrogate" error. This makes sense, > given that the string data got corrupted somehow, but the question is "what > is the proper way to deal with this in the module?" Should I just throw an > error on bad data? Or would it be better to set the errors parameter to > something like "replace"? The former feels a bit more "proper" to me > (there's an error here, so we throw an error), but leaves the end user dead > in the water, with no way to retrieve *any* of the data (from that row at > least, and perhaps any rows after it as well). The latter option sort of > feels like sweeping the problem under the rug, but does at least leave an > error character in the string to l > et them know there was an error, and will allow retrieval of any good > data. > > Of course, if this was in my own code I could decide on a case-by-case > basis what the proper action is, but since this a module that has to work > in any situation, it's a bit more complicated. > ----------------------------------------------- > Israel Brewster > Systems Analyst II > Ravn Alaska > 5245 Airport Industrial Rd > Fairbanks, AK 99709 > (907) 450-7293 > ----------------------------------------------- > > > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
