On 2011-12-25 11:31, Stefan Sperling wrote:
> On Sun, Dec 25, 2011 at 11:00:26AM +0100, Branko Čibej wrote:
>> On 25.12.2011 10:20, schamel23_at_spinor.com wrote:
>>> On 2011-12-25 06:37, Branko Čibej wrote:
>>>> There are always going to be cases where you have to
>>>> decide between aborting, or risking data corruption (or worse). Which
>>>> would you pick?
>>> Definitely data corruption, because (except for bugs) every data
>>> corruption is continuable and somehow recoverable,
>>> e.g. in the worst case by the user re-checking out the wc.
>> That's an interesting point of view. You are of course assuming that
>> such data corruption is easily detectable.
Cannot be and needn't be done.
> And that it doesn't waste
>> days of work.
> And that it isn't exploitable...
That's also not harder.
In the simplest case, basically the only thing you have to do
is replace all asserts by returning an error, possibly
also setting your wc handle to a cannot-be-used-anymore state.
(Even better, your code just reports an error and continues,
like if you open a word file but it cannot find a referenced
image file, but for svn there are probably not such cases.)
Yes, it requires a completely different programming philosophy.
But this is not more work in practice.
But of course, a programming language can help you a lot
> I don't think this conversation can get anywhere because the terms are
> too abstract. We should be discussing specific examples.
> Stefan already provided some and I agree that we've been using assertions
> too generously in some cases. In other cases they're warranted.
> We'll have to review our SVN_ERR_ASSERT calls and take appropriate
> action on a case-by-case basis.
Yes, I think this is the right approach in practice for svn,
and what Stefan would like to see.
But not only, I think the value of the "abstract discussion" is
influencing future API designs, e.g. as already mentioned by someone,
that every API function should be able to return an error
to not force the implementation to use an assert as last resort.
Received on 2011-12-27 10:11:51 CET