Let's try to keep this discussion about the use of assertions separate from the
thread about one particular instance. To that end, I've changed the Subject
line. (You should delete the "[was:...]" part when replying.)
The debate on the relative merits and appropriate usage of assert vs. error
return is tricky. We had a conversation about it a year or two ago which
didn't go far. There is a lot to learn. Our use of assert() is definitely
patchy and inconsistent.
Rather than debate this from scratch, there must be words of wisdom already
written that we can go and read to become familiar with the main arguments and,
hopefully, recommendations. Can we find some? I spent the last two hours
searching and reading stuff on the web; the best I found so far is
<http://www.lenholgate.com/archives/000525.html> which is a long rambling
discussion mainly about disadvantages of assert, hardly addressing server
software at all, and focused on C++ exceptions as the main alternative. I'm
sure someone can find a better on-line source of wisdom...
URLs please. Then we can discuss the issue knowledgeably.
(I'm quoting Stuart's email in full below, to make it easy for people to
respond to it under this new subject line. Don't say I didn't try!)
- Julian
..................
Stuart Celarier wrote:
> Garrett wrote:
>
>>So by your argument no code that can ever be used in a server process
>>can use assert? Sorry, I don't buy that, not by a long shot.
>
> No, I didn't say that at all.
>
> Karl wrote that there is an official policy on using assert in the
> Subversion code, but that it "is so common-sensical that we don't bother
> to write it down." [1]
>
> Can you help me understand what the official policy is? Maybe more than
> one thing can make common sense.
>
> Please understand that I am not trying to, as you said, make "a big
> stink" about this. I want to understand the project, and provide the
> honest perspective of users in the hope of making the project even
> better. I know that you and many others work hard on Subversion, and I
> truly appreciate that.
>
>
>>The
>>point of the assert is to keep the developers from misusing the API,
>>and to make it abundantly clear when the problem does crop up that
>>this is WRONG and needs to be FIXED. It does so by making it
>>impossible to ignore the issue, and the result is that the code
>>actually does get fixed as opposed to ignoring the problem. This is a
>>good thing, IMO.
>
> Again, let me respectfully disagree. Yes, it is a good thing for
> developers to learn when something is wrong. But doing so at the expense
> of user access and productivity is not a good thing. Surely server
> reliability counts for something.
>
> I am not seeing how assert makes the problem "abundantly clear" to the
> developers. The error is logged in the Apache logs, accessible to the
> server administrator. The user does not know what caused the server to
> abort, and, as in our case, he may even repeat the activity multiple
> times before the problem is diagnosed. That is not being "abundantly
> clear" to anyone, but it is rather effective at disrupting business. In
> my view, a user receiving an error message gets more details with more
> context and greater clarity (assert provides scant details), without
> penalizing all of the other users of all of the other repositories on
> the server; and that is far more likely to result in the problem being
> reported in a meaningful way to the developers.
>
> In the case of this issue [1], the problem cropped up and was logged
> four months ago. That identified it as "WRONG" and needing to be "FIXED"
> back in September: these things do take time, after all. But in the
> meantime the users keep getting the message -- the server is down again
> -- intended for the developers. That's a rather hefty on-going penalty
> in order to let the developers know that something is wrong.
>
> Of even greater concern, aborting the server makes an error condition
> into a denial of service exploit, which should be considered as a major
> security threat.
>
> Perhaps we can find a better way to meet the needs of both the
> developers and the users. It seems like there has to be some range of
> options between ignoring a programming issue and undermining server
> reliability.
>
> Best regards,
> Stuart
>
> Stuart Celarier | Corillian Corporation
>
>
> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=2398
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 14 04:52:19 2006