Will Dean wrote:
> At 10:46 08/02/2005 +0000, you wrote:
>
>> I think we _do_ need to be defensive in the shell extension. However
>> good the cache app, you can never guarantee that you haven't overlooked
>> something. As you say, catch(...) should be a last resort, but in the
>> absence of proper validation it's better than nothing.
>
>
> I strongly disagree, at least at this stage in development. I would
> much rather find problems with the cache now, than have them masked by
> dubious catch(...) blocks.
>
> The sequence of events goes like this:
>
> 1. I write bad, confusing code, which I think happened to be correct.
> 2. Someone else is understandably confused by the bad, confusing code
> and makes some changes to it, which do not improve its correctness (in
> fact, I believe they added at least one error)
> 3. The code is now bad, confusing and incorrect.
> 4. To avoid bad, confusing and incorrect code having an impact on the
> shell, an catch block is added to silently smudge across errors in the
> cache.
>
> My take on this is that we should be removing bad, confusing code from
> TSVN, not avoiding its symptoms. And this is doubly so at this stage,
> where we are asking early-adopters to help us test it.
Speaking as one of those early-adopters, I can tell you that I will
disable the new cache as soon as I see explorer crash because of it.
So far, nightlies have been reasonably stable, and I have never had
anything close to data loss caused by using them, so I feel confident in
using them for actual work. However, when this stability is sacrificed
to make bugs stand out, I cannot do that anymore.
So, yes, the bugs must be found rather than silently ignored, but the
way to do this should *not* be a crash. Why not show a popup when it
happens? or write to some log file?
Finding bugs by explicitly *not* preventing explorer crashes comes
across as a big "fuck you" to everyone using nightlies, but that may
just be my perception of things.
Regards,
Roel Harbers
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Feb 8 13:20:47 2005