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