On 2008-06-18 16:01:49 +0100, Julian Foad wrote:
> * "I do think that there is value in having a way of assert/aborting
> from anywhere in the code (not just svn_error_t-returning functions)
> which can't be ignored accidentally by forgetting to write SVN_ERR and
> friends." [DG]
>
> -> The traditional (standard) assert()/abort() achieves this, but I
> think you also accept that in the libraries we need to make such errors
> trappable by the calling program. My proposal solves this for the
> functions where an error return is available. I have no solution for the
> other functions, so they can continue to use the traditional
> assert()/abort().
Shouldn't these functions be modified to return a svn_error_t, or
isn't it possible (API compatibility)?
> * Allowing the application to continue (rather than aborting
> immediately) may be dangerous because undefined behaviour may lead to
> data loss. [VL]
>
> -> It MAY of course, but it's safer than the alternatives. Forcing the
> application to quit immediately when any unexpected condition is
> encountered is unacceptable behaviour for a library, and may cause loss
> of the application's data. It's better to allow the application
> programmer to control how the unexpected condition is handled. He can
> choose to make it always quit immediately if that is best for that
> particular program.
OK, but I don't think this is a really valid argument for the
following reasons. First, assert()/abort() is still currently used
(see above). Then, in particular because of this first comment (but
also because the application can crash in other places, either in
the library code or in the application code, due to a bug), the
application can still trap the signal(s) (this is C standard, isn't
it?) if it needs to save data and/or really wants to continue.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-19 13:56:10 CEST