On 24.12.2011 09:41, Stefan Küng wrote:
> On 23.12.2011 23:52, Branko Čibej wrote:
>> On 23.12.2011 18:49, Stefan Küng wrote:
>>> I have _repeatedly_ mentioned on this list that this kind of "error
>>> handling" (quotes intended) is bad. Sure, it won't affect the CL
>>> client that much, but for a library that's just not acceptable.
>>> But others have similar error handling implemented:
>>> http://thedailywtf.com/Articles/Serious-Failure.aspx
>>
>> Ranting is all very well, but I've yet to hear a suggestion from you
>> about how the libraries should handle unrecoverable errors. Like, for
>> example, the case where wc.db contains inconsistent and/or invalid data.
>
> Simple: return an error!
> That way the application can go on running, only the svn command is
> stopped.
> Sure, returning an error isn't always easy because it requires that
> you code a path to return to a known state. But for a library that's
> what has to be done.
In the case of Subversion, that would imply:
* second, removing all uses of SVN_ERR_MALFUNCTION* and SVN_ERR_ASSERT*;
* but first, making every library function return an svn_error_t.
I think that would be overkill. People tend to assume that any error
condition can be recovered from, but that's not the case at all. There
are many conditions where trying to recover from them does more damage
than hitting the big red button.
I could easily turn your reasoning around and simply state that you're
not using the libraries correctly, since you knew from day one that they
can "throw unrecoverable errors" (which is what assert() is all about,
after all), and therefore you should not be loading SVN libraries
directly into an Explorer process but should instead spawn them in a
separate, isolated daemon process and RPC that from your shell
extension. Sounds fun? No doubt. My guess is that it's less work than
making every possible error condition that the Subversion libraries can
encounter recoverable.
It's not even a valid argument to say that the libraries, such as they
are now, are not suitable for UI development, since not every UI is such
that a glitch in one of its plugins effectively brings down the whole
system. The Explorer extension environment is an exception. It's
basically your responsibility to take that into account, and whilst it's
reasonable to expect the SVN libraries to meet you halfway, it's quite
unreasonable to lay all the blame for your problems at their (rather,
our) doorstep.
> I think I've explained my reasons enough already, so I'll stop now.
The reasons are obvious, the method is what needs working on, that's all. :)
-- Brane
Received on 2011-12-24 11:24:55 CET