[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Error exit conditions from svn binaries

From: Daniel Shahaf <d.s_at_daniel.shahaf.co.il>
Date: Tue, 22 Apr 2008 00:36:49 +0300 (IDT)

Stefan Sperling noted on IRC that the svn command-line tools respond to
errors in main() in different ways:

        1. svn_handle_error2(force = False);
        2. svn_handle_error2(force = True);
        3. return svn_cmdline_handle_exit_error(svn_error_t *error);
        4. SVN_INT_ERR(expr);

which, respectively,

        1. print an error chain and return to caller;
           (this call is sometimes used to print warnings)
        2. print an error chain and abort();
        3. Call svn_handle_error2(@a error, stderr, FALSE, @a prefix), clear
           @a error, destroy @a pool iff it is non-NULL, and return
        4. Evaluate @a expr. If it yields an error, handle that error and
           return @c EXIT_FAILURE.

svn_handle_error2 has the following comment:

  if (fatal)
    /* XXX Shouldn't we exit(1) here instead, so that atexit handlers
       get called? --xbc */

Further, in r24415 Malcolm Rowe converted numerous exit paths to use
svn_cmdline_handle_exit_error(), noting that that fixed error leaks and
prevented aborts in maintainer mode. (If I understand correctly, the
aborts were caused by exiting the process before destroying the
top-level pool.)

Given that aborts are bad, would it make sense to (a) implement xbc's
comment quoted above; (b) change all exit paths of types (2) and (4) to
use svn_cmdline_handle_exit_error, and document that for posterity?


P.S. Stefan also suggested adding a warning to SVN_INT_ERR that it
should not be used in a main() due to maintainer-mode aborts;
I suggested a wording here: <http://paste.lisp.org/display/59488>.

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-22 08:36:59 CEST

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.