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:08:10 2006