[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-dev
Subject:    Re: abort() calls
From:       "C. Michael Pilato" <cmpilato () collab ! net>
Date:       2007-04-30 20:03:18
Message-ID: 46364B86.60302 () collab ! net
[Download RAW message or body]


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


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]