<!-- Kamailio Pull Request Template -->
<!-- IMPORTANT: - for detailed contributing guidelines, read: https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md - pull requests must be done to master branch, unless they are backports of fixes from master branch to a stable branch - backports to stable branches must be done with 'git cherry-pick -x ...' - code is contributed under BSD for core and main components (tm, sl, auth, tls) - code is contributed GPLv2 or a compatible license for the other components - GPL code is contributed with OpenSSL licensing exception -->
#### Pre-Submission Checklist <!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply --> <!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above--> <!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list --> - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [X] Each component has a single commit (if not, squash them into one commit) - [X] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change - [X] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [X] PR should be backported to stable branches - [X] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description <!-- Describe your changes in detail -->
Python's C interface contract states that C code must *either* raise an exception and return NULL, *or* return a Python object.
Doing both will raise a `SystemError` exception which obscures the original problem. It may also cause a memory leak. You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4044
-- Commit Summary --
* app_python3: fix exception handling
-- File Changes --
M src/modules/app_python3/apy_kemi.c (4) M src/modules/app_python3s/apy3s_kemi.c (4)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4044.patch https://github.com/kamailio/kamailio/pull/4044.diff
Closed #4044.
I think the code is better how it is because the second parameter of the function you gave as example in the issue has to be a valid string. In the current form, it indicates there is a problem with the parameter, rather than having it silently not doing anything when it was expected to be a change of the value. As commented in the issue, use sr-users mailing list if you want to discuss further.
You seem to have misunderstood me here. I am **not** trying to suppress the exception. I am trying to make sure that the programmer gets the **correct** exception (`TypeError`) handed to them.
The Python C interface documentation is pretty clear on this point. You MUST return NULL instead of a `PyObject*` when your C code has set an exception. The resulting `SystemError`, on top of the `TypeError` the calling Python code *should* be getting, is a pretty clear and unequivocal demonstration of this, and it even says what's wrong ("SystemError: <built-in function sets> returned a result with an exception set"). See my bug report for the example stack trace.
NB: Two years ago I found another example of this problem which was fixed in b7911b6.
Re-opened, as there seems to be still discussions necessary if the python KEMI interface should be adapted to the interface documentation.
Reopened #4044.
OK, thanks for explaining further -- as a not much expert in python, it looked like hiding it by not providing the right parameter, so if I got it wrong, then it is fine to merge.
Merged #4044 into master.
Thank you.
-
Daniel-Constantin Mierla -
Henning Westerholt
-
Matthias Urlichs