Garrett Rooney wrote:
> On 2/13/06, Stuart Celarier <SCelarier@corillian.com> wrote:
>> Garrett wrote:
>>> Why change from an assert to a SVN_ERR? The assert was wrong because
>>> of the pointer comparison, not because of what it's testing, it's
>>> still fundamentally misusing the API to pass two different filesystems
>>> to this function, so why not make it an assert?
>> Yes, the pointer comparison was wrong, but aborting the server because
>> of a recoverable error condition is also wrong. Recovery, in this case,
>> would mean letting the calling operation can fail gracefully.
>>
>> With all due respect, what value is provided by aborting the server? I
>> don't see that restarting the server after it has aborted corrects the
>> situation. So why abort in the first place? How is that better than
>> failing the operation?
>
> 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. 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.
Depends - if it is an internal function, assert/abort() is a good way to
enforce "should never happen" type of behaviors. However, if this can
be triggered by wire data, you have a major bug in that a simple DOS
attack of sending that wire data will abend the server. Nothing that
ever comes over the wire should ever abend the server. Remember, the
wire is open to anyone sending packets, including old, broken clients and
malicious code.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 14 12:08:32 2006