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
catch
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
Hector Correa