I am not sure what book you are talking about and the context that the author is using.

What I've heard is people using TRY/CATCH to detect things like if a property exist in a class like in this example:

try 
   myclass.nonexistingproperty = 8
   ' the property exists then do XYZ
catch
   ' the property does not exist then do ABC
endtry

I've never benchmarked code like this in .NET, but I am pretty sure that the exception thrown when the property is not found could significantyl drag performance if this code is in a loop.


>Thanks for the response. I'm quite happy with Try/Catch so long as 1 can throw errors to a central documentor if I can't handle them. I was just worried that I'd go the wrong end of the stick and confused at one book that. after detailing Try/Catch as the great new error trap implied that it invoked a heavy overhead and should only be used when you are deliberately risking an error.
>
>Thanks again
>
>Andrew