Message73328
| Author |
vstinner |
| Recipients |
amaury.forgeotdarc, jcea, vstinner |
| Date |
2008年09月17日.09:38:03 |
| SpamBayes Score |
3.5791486e-10 |
| Marked as misclassified |
No |
| Message-id |
<200809171137.44812.victor.stinner@haypocalc.com> |
| In-reply-to |
<1221641624.71.0.373281108932.issue3885@psf.upfronthosting.co.za> |
| Content |
> gc.collect() is just a rude way to display this "XXX undetected error".
> (Victor: does Fusil check for this? gc.collect() will not fail if there
> is another exception in-between, or in debug mode)
I stopped to fuzz Python using --pydebug because a critical design error in
CPython reference counting: http://bugs.python.org/issue3299 (some modules
use PyObject_DEL() instead of Py_DECREF() whereas PyObject_DEL() creates
inconsistent objects in the double linked object list). Since nobody cares
about this issue, I don't use pydebug anymore.
> Now, to the _bsddb module: in general, the following pattern is wrong:
> dummy = someFunction();
> Py_XDECREF(dummy);
> because it does nothing about an eventual exception set. If the
> exception can be discarded, PyErr_Clear() must be called.
Well, we have to choices: don't raise an error, or clear the exception if an
exception is raised.
> I think there is an invariant to keep in each function: return NULL if
> and only if an exception is set. Many places in _bsddb do not respect this.
Where? dealloc() callback prototype is "void tp_dealloc(...)": no result! It's
not possible to tell Python that an error occured. |
|