[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [TSVN] Re: Changes in 2634

From: Will Dean <svn_at_indcomp.co.uk>
Date: 2005-02-08 12:09:49 CET

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.

I would really like people to review my code, suggest improvements, find
bugs, etc. That's not the problem at all, and I don't want anybody to get
that impression.

>You would have to hire a Doctor Octopus costume to wear them all (nearly
>all), and then you run the risk that people won't take you seriously ;-)

I was planning to wear them sequentially.

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 12:11:44 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.