>So just for curiosity.
>How do you figure out using an outer TRY CATCH where an error occur? method, object, topmost container object for those object, class and library of the both objects.
>
>Lutz

Try/Catch is not meant to be used as outer error trapping ONLY, for this use ON ERROR. When used as outer error trapping you just get the name of the failing procedure and code line number, but not the library or the name of the program or the variables out of scope. This is because Try/Catch is meant to be used in each procedure on which you want special control, and from this procedure you can rethrow the exception with all the information and details to the outer level, even local variables data because they are allways in scope of the local Try/Catch handler (if any).

Error event is not meant to be used as external error traping ONLY, and using it as outer error trapping doesn't collect all the info you said on top, just nError, cMethod and nLine (like Try/Catch does), and that's why you need to put it at the class level so can be instantiated and can collect the object data and more data, but you cannot collect data of local variables, which Try/Catch can do, and this local data is very useful for diagnosing problems, but local vars are allways out of scope for the Error event.

So at the end, if used correctly Try/Catch can collect more specific data than Error event, even the object data if you like. Apart from this, it is much more predictabe and easy to maintain than the error event, and I've used error event for many years, so I know about the problem it causes, and that's why I can do this comparison, and Rick too.

To compare different error handlers, the comparison must be made using the specific implementation of each one. You can't evaluate a Try/Catch from the perspective of the implementation of the Error event, because it is a very different implementation.

* Error event works at object level, so you loose the details inside the methods of the object, you cannot easily define the flow of the error path and you cannot do proper garbage collection

* Try/Catch works at method level, so you can get all the details inside the method (local vars), object data if needed, and act in consequence, so you can easily define the flow of the error because corresponds exactly to the callstack, and do proper garbage collection in each step

Benefits can be achieved and evaluated only when using it correctly.