PEP 249 Compliant error handling

[Cameron Simpson]

On 17Oct2017 21:38, Karsten Hilbert <Karsten.Hilbert at gmx.net> wrote:
>> That's certainly a possibility, if that behavior conforms to the DB API "standards". My concern in this front is that in my experience working with other PEP 249 modules (specifically psycopg2), I'm pretty sure that columns designated as type VARCHAR or TEXT are returned as strings (unicode in python 2, although that may have been a setting I used), not bytes. The other complication here is that the 4D database doesn't use the UTF-8 encoding typically found, but rather UTF-16LE, and I don't know how well this is documented. So not only is the bytes representation completely unintelligible for human consumption, I'm not sure the average end-user would know what decoding to use.
>>
>> In the end though, the main thing in my mind is to maintain "standards" compatibility - I don't want to be returning bytes if all other DB API modules return strings, or visa-versa for that matter. There may be some flexibility there, but as much as possible I want to conform to the majority/standard/whatever
>
>
>The thing here is that you don't want to return data AS IF it was correct despite it having been
>"corrected" by some driver logic.

I just want to say that I think this is correct and extremely important.

>What might be interesting to users is to set an attribute on the cursor, say,
>   cursor.faulty_data = unicode(faulty_data, errors='replace')
>or some such in order to improve error messages to the end user.

Or perhaps more conveniently for the end user, possibly an option supplied at 
db connect time, though I'd entirely understand wanting a cursor option so that 
one can pick and choose in a fine grained fashion.

Cheers,
Cameron Simpson <cs at cskk.id.au> (formerly cs at zip.com.au)