On 12/27/10 1:20 PM, Daniel Shahaf wrote:
Blair Zajac wrote on Mon, Dec 27, 2010 at 12:47:23 -0800:
On 12/27/10 11:49 AM, Daniel Shahaf wrote:
Also: formally, if you just got an SVN_ERR_ASSERTION_FAIL, the API
contract doesn't allow you to continue calling into svn libraries. In
other words, unless you verify that the "expected" assertion was
triggered, some day we might change the code, the test will hit some
other assertion --- and will happily ignore it :(
Where is this documented? That doesn't make sense in a multi-threaded
context as one would have to stop all threads.
I'm not sure where it's documented.
The closeest I find in the API docs is that svn_error_malfunction_handler_t's
docs allow the handler to choose between never returning and returning
SVN_ERR_ASSERTION_FAIL.
Perhaps someone else has a better API/dev@ reference...
There's always a chance we may catch another error if we change the code,
don't know if there's much to do about that.
Yeah, but my point was: what if after changing the code the test
*unintentionally* hits an assertion? i.e., not the "No non-tracing
links" assertion, but some other assertion.
We could assert that the file line number matches the expected line. I'm doing
this now.
Found a bug in svn_error_raise_on_malfunction() when doing this.
Blair
