>>I would disagree with all my respect. You can of course run some code that you may have issues with and continue linear execution if an error occurs. There isn't any issue in managing it.
>>
>>As I said, "personally", everyone is on his own. I prefer ON ERROR.
>
>The trouble with try-catch is that is quite useless if not really local. It's like american health insurance, you have to know in advance which diseases you want to prevent and insure against them. Which means that if you insure your knees, you still may get in trouble with your ankles. A generalized try-catch somewhere at app launch will save you from general trouble of app crashing, but that's about the extent of it - the exception object doesn't have results of aStack() in itself, only the method and line number etc, which is better provided by On Error. Now the trouble is that if, for instance, you wrap a createobject() of a rich container in try-catch, it won't tell you, when something happens during instantiation, where it happened. You may know that it's a textbox1, but not in which container or column.
>
>So while it's a good tool to have for places where you expect trouble - dealing with external files or devices which may or may not be there, may be locked or protected - for unexpected trouble, and specially for debugging it, On Error.
>
>And, BTW, I have rarely used the .error() method and actually regretted it each time. It's more trouble than it's worth.

Yes, I too almost never used .error method.