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

Re: use of SVN_ERR_ASSERT (was: svn commit: r1302682 ...)

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Thu, 22 Mar 2012 12:54:30 -0500

On Thu, Mar 22, 2012 at 12:36 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Thu, Mar 22, 2012 at 13:33, Daniel Shahaf <danielsh_at_elego.de> wrote:
>> Greg Stein wrote on Thu, Mar 22, 2012 at 13:19:41 -0400:
>>...
>>> Daniel removed one of these ASSERT uses a day or two ago. My
>>> assumption was that he was referring to that, rather than the ###.
>>>
>>
>> Yes, by "these" I referred to to the use of assert(), abort(), and
>> svn_error__malfunction().
>
> Oh, I definitely don't want to see any assert() or abort() calls. With
> you there.
>
> But if you're suggesting that we stop using SVN_ERR_ASSERT(), then
> that is a much larger question. I see no problem using them. "If we
> don't have what we expect, then we've got big problems."

I think it goes beyond "we don't have what we expect, therefore ..."

In some cases, we really don't have any idea of how to proceed.
Examples: abuses of the APIs; invalid data from an unknown source;
database in some invalid, unrecoverable state; etc.

In others, we can gracefully fail. Examples: data input from the
command line or the network; missing files; etc.

In the former case, abort()s (or their equivalent) are warranted,
because we don't have any valid way to continue. The latter case,
which I think is far more often, we can at least return some
information to the user without crashing the library and any
applications using it. I think that's what we should attempt to do
with most of our "invalid state" errors.

While I've no doubt that *you* appreciate this nuance, I feel it
should still be pointed out. :)

-Hyrum

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-03-22 18:55:03 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.