I would only add that ON ERROR is not something on which you can rely. In our framework, we have a ReadEvents class and it has the global error handler call in its Error method. So any ON ERROR will never hit because the Error method in the call stack takes precedent. TRY/CATCH is, as Dragan mentioned, for localized issues when an error may occur that cannot be accounted for in code. XFRX uses an ON ERROR, as I recall, and I had to remove them and switch to Error methods to get back to the same behavior.

>>Why would someone dislike TRY/CATCH when it's really a great and simple thing?
>
>I can't explain it. There's something about it that I dislike. Always have. I don't know why. It's the same reason I will never support anything related to Apple's hardware or software. I will go and be a farmer before I ever write a single line of code to support the things of Apple. It's the same with TRY..CATCH. I don't know why.
>
>FWIW, I don't feel as strongly about TRY..CATCH as I do about Apple, and I have agreed to support the command in Visual FreePro. However, there is something that I've since developed called FLOW..ENDFLOW which handles not only errors, but messages, and it does so with the explicit ERROR keyword, allowing it to be handled in a more appropriate way, along with other flows which can remove nested source code out to a more left-justified and documented level.
>
>See: http://www.visual-freepro.org/wiki/index.php/Flow_Control#FLOW..FLOWOUT..FLOWTO..SUBFLOW..FUNCTION..MESSAGE..ERROR..ENDFLOW
>
>And look specifically at the "General form" near the end of the code block.