[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1053140 - /subversion/trunk/subversion/tests/libsvn_subr/error-test.c

From: Blair Zajac <blair_at_orcaware.com>
Date: Mon, 27 Dec 2010 14:09:19 -0800

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
> 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.

Received on 2010-12-27 23:10:04 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.