Hi Rick,

you are right with most of it.
Only as I lay out before the nobody look at those logs is simply me. So customer is used to ship the log if he runs into some error and I'm used to look at it on top of all. So I normaly have a good idea where and why to look while the data I need for testing is still on transfer. :)

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

>Lutz,
>
>I wasn't suggesting you rip out all your code and replace it with TRY/CATCH. What I was pointing out that IF POSSIBLE that when you start from scratch or refactor code, using TRY/CATCH is a better approach. If you have a ton of code that already uses .Error() methods it's going to be very difficult to replace that code with TRY/CATCH because it's a completely different methodology (outside in vs. inside out) and as you point out that's a lot of effort that doesn't have a ton of benefit.
>
>But I don't agree that you can't get relevant error information without using .Error() methods - you can. No not an object and state (although you can still do memory dumps if you really want that). for the most part logging all of that is a good way to ensure nobody ever looks at the error logs :-). Full dumps of objects and memory should be a last ditch debugging issue, not a 'do all the time' issue for many reasons. There are more effective ways of doing this with tracing in your apps. 90% of the hard to find errors in applications tend to be logic errors not crash errors and those don't leave an error log in the first place...