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

Re: abort() calls

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-04-30 22:03:18 CEST

Stefan K√ľng wrote:
> Greg Hudson wrote:
>> It's already our policy to throw an error--and not abort--when any
>> external error occurs, even if it's an unexpected error like data
>> corruption. The only exception is out-of-memory errors; as with most
>> code, Subversion considers it too burdensome to recover from allocation
>> failures since allocations occur so often.
> I can accept that policy. But when you look at the code in trunk right
> now, you'll find a *lot* of places where abort() is called just because
> something isn't as expected. For example, I found some in the libsvn_wc
> part where abort() is called simply because the entries file doesn't
> have an entry which is expected. And that's something which must not
> happen: corrupted working copies *can* happen, and especially for TSVN
> it's not acceptable to have the whole explorer and desktop shutting down
> simply because of that.

I agree, that's an example of a bad abort().

For myself, I try to apply the simple rule of thumb that abort() is useful
for punishing naughty programmers (that is, those who pass malformed data
into functions they call), but otherwise, it's probably a return-an-error
situation. Bad data on disk doesn't violate the API contract, so ideally
shouldn't trigger an abort.

C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Mon Apr 30 22:03:29 2007

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.