[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2007-04-30 21:10:50 CEST

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.

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:09:04 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.