On Thu, 2008-06-19 at 13:55 +0200, Vincent Lefevre wrote:
> On 2008-06-18 16:01:49 +0100, Julian Foad wrote:
> > [...] 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)?
I think it would be best to have that discussion in a new thread some
time.
> > * 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
The fact that assert()/abort() is still currently used in some places
does not mean it's not useful to be able to handle many other
assertions. There will always be ways in which an imperfect C program
can crash even if we were to take out all of the deliberate abort()
calls.
> (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.
The difference is that, with a signal, the top-level application (e.g.
Windows Explorer with Tortoise plug-in) would handle the signal and
would presumably have to abort because it can't recover to a clean place
higher up the call stack.
On the other hand, with an assertion reported as svn_error_t, an
intermediate layer (such as TortoiseSVN) can trap the result of calling,
say, svn_client_status(), and report to the user something like:
[[[
Tortoise encountered an internal error in Subversion. The operation
was not completed. Continuing may result in undefined behaviour. If
you choose "Continue" you should try to save your work straight away
and then re-start Explorer manually.
[Continue] [Show Details] [Restart Explorer]
]]]
The advantage here is that in many cases choosing "Continue" will enable
the user to avoid losing work in progress, such as by saving the commit
message he'd been composing in Tortoise's commit dialogue box.
- Julian
---------------------------------------------------------------------
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 16:24:44 CEST