Will Dean wrote:
> At 13:44 08/02/2005 +0000, you wrote:
>> Nobody doubts your commitment, or the huge improvements you have
>> made. But you do seem to be taking a piece of defensive programming
>> in the shell extension as an attack on the quality of the cache code.
>
> Not at all. I very strongly feel that it damages the product to
> slap-in catch(...) handlers (or similar) without really being sure
> why, and I refute the justification of this as being 'defensive',
> in any useful fashion.
Agreed. The catch(...) really should be there only as a last resort to
pick up on anything the 'proper' error handling has omitted to check.
> Another offer of a patch...? :-)
Sorry, but no. I'm no VC++ programmer.
/me whistling quietly in background
> Personally, I would be very cautious about adding a message-box (or
> similar) to the shell extension in this context. As well as the fact
> that if you get to a catch(...) handler under VS then you have no
> idea about how you got there or why or what the state of the system
> is, you also have the issue that you're trying to put a
> message-box-up inside another process, which you know nothing about.
>
> It seems to me that this is an invitation for something even more
> horrible than an Explorer process crash - potentially it's some kind
> of deadlock, for example.
Fair point. Is appending to a log file any better?
>> Whether this particular bug exists or might cause a crash is almost
>> irrelevant. There is no reason not to provide a safety net to prevent
>> future or as-yet-undiscovered bugs from creating havoc, provided
>> that it exposes the bug instead of masking it.
>
> Sure. And I might be persuaded by well-made arguments that the shell
> should validate data coming cross-process from the cache. I don't
> believe that a catch(...) block in one of the places which the shell
> consumes this data is the place to do this, and is almost certainly
> not the best technique.
No. As I said, it should be the last resort, not the first.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Feb 8 16:11:21 2005