Branko Čibej wrote:
> Stefan Küng wrote:
>> In the Subversion code, there are a lot of calls to the abort()
>> function. I think those should be removed and replaced with something
> Oh wow, you've gone and opened a can of worms that we've had trouble
> closing in the past.
> A note about assert vs. abort: As long as it remains common practice on
> Windows to compile release binaries with NDEBUG defined, assert is worse
> than useless.
> Also, returning an error implies that we can (somehow) recover from it,
> which isn't always the case.
> We probably do call abort() in places where we could do something else;
> such bits can be fixed. But we decided long ago on the policy to not
> cater to clients that violate the API contract, so returning an error in
> those cases would mean changing that policy. Nothing wrong with that in
> general, it's just yet another can of worms.
> I'm willing to consider using something else instead of abort(). But
> someone will have to come up with a proposal that works everywhere, not
> just in Windows GUI with just-in-time debugging.
Two possibilities come to mind:
Stefan, we could use _set_abort_behavior() to turn off
the stupid message and turn on normal fault handling (in fact,
I'm about to send a message off to our development group suggesting
we do the same in our commercial apps.)
A better alternative, in my opinion, would be to establish a
subversion function, something like:
typedef void (*PFN_abort)();
void svn_set_abort_function(PFN_abort pfnAbort);
The abort function would default to the standard abort, but
TSVN could call and set the abort function to a function that
throws an exception caught back at the original call site
The only problem with this is that we'll leak any resources
allocated by TSVN during the function that triggered the abort,
but I don't see a good way around that...
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Apr 29 05:34:35 2007