[ZODB-Dev] Re: raising ConflictError from C (was: Latest news: core dump ...)
Greg Ward
gward@mems-exchange.org
Thu, 4 Oct 2001 15:17:46 -0400
On 04 October 2001, I said:
> I'm not sure of the best way to fix this. The most obvious is to do the
> C equivalent of this:
> except:
> (error, value, traceback) = sys.excinfo()
> raise ConflictError(str(value)), traceback
>
> -- ie. don't pass an arbitrary exception object to the ConflictError
> constructor, instead use its stringification as the ConflictError's
> message.
OK, I've coded this in C, added it to BTreeBucket.c
(BTree__p_resolveConflict()) and BucketTemplate.c
(_bucket__p_resolveConflict()), and now the testConflict test passes
with flying colours. Here's the code:
err:
if (r) {
ASSIGN(r, Py_BuildValue("((O))", r));
} else {
PyObject *error;
PyObject *value;
PyObject *traceback;
PyObject *args;
PyObject *str_value;
/* Change any errors to ConflictErrors */
PyErr_Fetch(&error, &value, &traceback);
/* XXX error-checking! */
if (value != NULL) {
args = PyTuple_New(1);
str_value = PyObject_Str(value);
PyTuple_SET_ITEM(args, 0, str_value);
Py_DECREF(value);
} else {
args = PyTuple_New(0);
}
value = PyInstance_New(ConflictError, args, NULL);
Py_DECREF(args);
Py_INCREF(ConflictError);
Py_XDECREF(error);
PyErr_Restore(ConflictError, value, traceback);
}
Yes, I know there's no error-checking there. I wanted to make sure it
works first. Another problem: previously, there were 7 lines of
duplicate code between BTree__p_resolveConflict() and
_bucket__p_resolveConflict(), which is probably acceptable. Now the
duplication is 18 lines; after I've added error-checking, it'll be even
more. That makes me nervous; I really don't like copy 'n paste code
reuse. So where should a mythical
convert_arbitrary_exception_to_ConflictError() function live?
Greg
--
Greg Ward - software developer gward@mems-exchange.org
MEMS Exchange http://www.mems-exchange.org