Bill, sorry for the delay in replying. To answer your unspoken question, yes and no - the code was answering the premise that exception handling should not be relied upon when a simple check can solve the issue. So, what is the error we're coping with in this example? It's the fact that you can't write a file into a directory until that directory exists. The other side here, is the fact as you've rightly pointed out, that this doesn't address all the cases that can be tested for. In my defence, I wrote this as a cut-down sample in the CP editor as an example only, but you are right, there are many other conditions that could be catered for. The point is really two-fold, if you create a utility API to handle the conditions that you can test for (rather than catch as an exception) then you have given yourself a real advantage when you come to write your production code. No, you won't get rid of exception handling altogether, but you won't be relying on it to cope with conditions that could easily have been tested for. So, why do I advocate this? Well, exception handling is meant to indicate something that you couldn't reasonably predict and cope with. The mark of a good application is one that doesn't surprise users, so I'm either going to have to do lots of try/catch (and then cope with the failure before triggering the condition in the try/catch again), or I can put something in place to cope with the error before it occurs and make an intelligent decision about coping with the problem. I hope this somewhat rambling post conveys some of what I was trying to get across.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility