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
Received on 2010-12-27 23:10:04 CET