[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: Mark Phippard <markphip_at_gmail.com>
Date: 2007-04-30 21:13:48 CEST

On 4/30/07, Greg Hudson <ghudson@mit.edu> 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.
> It's currently our policy to assert or abort when a coding error is
> detected. There are a couple of reasons for this:
> 1. It's impossible to protect the caller from all coding errors; buggy
> C code can always cause a crash. (There's a counterargument: the
> calling code might be written in a safe language like Python, using the
> Subversion bindings. In many cases the bindings might be able to check
> for invalid inputs and throw language-specific exceptions, but not
> necessarily all cases.)
> 2. There are interfaces like svn_path_basename which are much more
> convenient to use if they can be assumed to always succeed--which they
> will if they are provided with valid inputs.
> If you find a place where an assertion failure or abort could happen as
> a result of an external factor like corrupt data files or invalid
> command-line or network input, that's a bug.

I reported one over the weekend. This command using ra_serf aborts:

svn info http://svn.collab.net/repos/svn/trunk/file_that_does_not_exist

When using something like Subclipse, this causes the entire IDE to just close.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 30 21:13:59 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.