Julien Palard added the comment:
By moving:
```
/* else set the right exception and return NULL */
PyErr_SetString(pysqlite_ProgrammingError, "can't adapt");
```
from `pysqlite_microprotocols_adapt` to `pysqlite_adapt` (to avoid changing the
semantics from the outside) make the `pysqlite_microprotocols_adapt`protocol
clearer:
- if it went well return something
- If it went well but had nothing to do: return NULL
- If it broke, set an exception and return NULL
It does not break any test. Then in `Modules/_sqlite/statement.c`, we can stop
blindly muting exceptions with the `PyErr_Clear`s, replacing them with ``if
(PyErr_Occurred()) return;``. Again it does not break any test.
I added a test to check that if an adapter raises an exception it bubbles
outside the execute method, and it passes.
Sample code given by the issue now gives::
$ ./python issue28729.py
Traceback (most recent call last):
File "issue28729.py", line 18, in <module>
cur.execute("select ?", (p,))
File "issue28729.py", line 10, in adapt_point
assert False, 'Problem in adapter'
AssertionError: Problem in adapter
I did not found precise documentation about pysqlite_microprotocols_adapt or
pysqlite_adapt, so my changes may break a "well known protocol", but it looks
safe as I do not change the _sqlite protocol as far as I can tell, (only when
the exception comes directly from the adaptor, obviously), and there were no
other uses of pysqlite_microprotocols_adapt, which is not exposed in the module.
----------
keywords: +patch
Added file: http://bugs.python.org/file45540/issue28729.patch
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28729>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
