Branko Čibej wrote:
> Jonathan Gilbert wrote:
>> What about -- on platforms that support it -- allowing the project calling
>> into the library to provide a jmp_buf to be longjmp()ed to instead of
>> abort()ing, and replacing the abort() calls with calls to a wrapper
>> function to pick between that and abort() if the user hasn't provided a
>> jmp_buf (or the platform doesn't support it)?
>>
>
> The number of implicit +1s to this proposal really make hair stand on end.
>
> The following really applies to any kind of abort() alternative, but
> longjmp sticks out.
>
> * How do you get the right jmp_buf to all the necessary places in
> all the Subversion libraries? we don't pass around a context
> object where it could be stored.
> * What do you do with dangling resources (open files, etc.) that
> can't be cleaned up after a longjmp?
> * How do you safely do /anything/ but end the process after you
> catch a longjmp?
>
> In other words: how is the cure not worse than the disease?
I think the best cure would be to never have to use neither abort() nor
any of the workarounds. IMHO there's never a good reason to use abort()
instead of properly returning an error.
After all, we're talking about the Subversion *library*, not the command
line client. And a library should never dictate how an application which
uses that library should behave. The application should always be the
one to decide what to do in case of an error situation. ALWAYS!
Because, as I pointed out several times now: it's simply not acceptable
for e.g. TSVN to call abort() in its shell extension. And with those
calls in the Subversion library, I'm really starting to think that I
have to start patching the Subversion code because of this.
Imagine you would use e.g. a jpeg-library to load/save jpeg images. Now,
the library detects some illegal sequence while loading a file and just
calls abort() - would you keep using any image editor which showed such
a behavior? I wouldn't! Because I would expect the image editor to show
me an error that the file is not valid and can't be loaded. Not some
"this application has requested the runtime to close" or something like
that and then simply quit.
But that's exactly what Subversion currently forces all Clients to.
I suggest that we review the code, and check *all* places where abort()
is called and find a way to return an error instead.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 30 20:50:27 2007