If a script causes an error, TC will either terminate the test run or just go on, depending on the "stop on error" option. In both cases, trying to find the cause of the error is very time consuming...
Well, I was complimenting a bit too quick.
The option works, if my scripts (script extension) post an error using Log.Error(). Then the run pauses in the next line, OK.
If You use error message event handling, it will not help You. I use it to suppress certain technical or known functinoal errors.
When some other error occurs during the test run (which is what the request is basically aiming at), the test run stops inside my error event handling routine. This does not help at all.
Even worse, for some kinds of errors suppressed in the error message handler, the test run stops in some infrastructure routine, making this completely useless: The infrastructure class provides my script extensions with access to TC internal libraries as Options, Dll, Win32Api. So when an error occurs in a script extension and is suppressed in the message handler, the run stops when the script extension calls the standard script with this class.
The approach could work perfectly, if it would be possible to prevent the pausing for specific code regions.
Right now, it does not help.