At 13:44 08/02/2005 +0000, you wrote:
>Whoa! We want as many testers as we can muster, so we _do_ care. In
>particular we want users with old & slow PCs to tell us about effects
>that will never show up on your blindingly fast PC. And those same users
>may suffer more pain from a crash than you do in terms of waiting for
>Windows to pick itself up.
That was in response to a threat which I perceived as being along the lines
of 'if your nightly ever crashes then I'll won't do any more testing'.
>Not yet, but that's not to say that it won't at some point in the
>future. The last few emails in this thread have demonstrated how easy it
>is for you and Stefan to misread each other's code. It could be Stefan
>adding code that causes a crash.
I'll grudgingly concede the last point ;-)
>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.
>No debate there, bugs should not be concealed. But nor should they be
>allowed to cause an explorer crash. The catch(...) would be OK if it
>threw out a warning rather than silently hoovering up the evidence.
Another offer of a patch...? :-)
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.
>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.
I loath 'programming by superstition', and I'm always prepared to argue
against it.
Cheers,
Will
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Feb 8 15:30:22 2005