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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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