On 24.12.2011 11:53, Stefan Sperling wrote:
> On Sat, Dec 24, 2011 at 11:24:14AM +0100, Branko ÄŒibej wrote:
>> On 24.12.2011 09:41, Stefan Küng wrote:
>>> On 23.12.2011 23:52, Branko ÄŒibej wrote:
>>>> Ranting is all very well, but I've yet to hear a suggestion from you
>>>> about how the libraries should handle unrecoverable errors. Like, for
>>>> example, the case where wc.db contains inconsistent and/or invalid data.
>>>
>>> Simple: return an error!
>>> That way the application can go on running, only the svn command is
>>> stopped.
>>> Sure, returning an error isn't always easy because it requires that
>>> you code a path to return to a known state. But for a library that's
>>> what has to be done.
>>
>> In the case of Subversion, that would imply:
>>
>> * second, removing all uses of SVN_ERR_MALFUNCTION* and SVN_ERR_ASSERT*;
>
> I disagree. I am still putting assertions into the code at spots where
> they are useful to catch bugs that get introduced by future code changes.
> Just recently I added assertions to the hotcopy code to check variables
> we rely on having certain values. That's totally fine. I made our test
> suite exercise these assertions to make sure they don't trigger when
> a hotcopy is made.
asserts are not bad per se. They're very useful in debug builds. But for
release builds they have to be replaced by something that returns an
error message.
That's why the c-runtime assert() is changed to an empty statement when
NDEBUG is defined for release builds.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2011-12-24 11:58:30 CET