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

Re: svn commit: r1222522 - /subversion/branches/1.7.x/STATUS

From: Branko Čibej <brane_at_apache.org>
Date: Sat, 24 Dec 2011 16:44:12 +0100

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.

Exactly. So do I. :)

>> * but first, making every library function return an svn_error_t.
> I doubt that's really an issue.
> Virtually any important call TSVN needs does return svn_error_t already.

Ah, but our private functions definitely do not.

Just saying, if we wanted to have a "completely recoverable" error
handling model, then what I said is what would have to be done. With the
obvious alternative of doing setjmp/longjmp magic, but that's a /really/
bad idea.

-- Brane
Received on 2011-12-24 16:44:53 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.