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
