You can effectively debug your ATEasy programs because ATEasy provides error handling and exception handling capability.
ATEasy displays two types of errors, Compiler Errors, Run-Time Errors and Fatal errors.
Compiler errors occur when ATEasy compiles the code. Compiler errors can occur when you do any of the Build, Check, Doit, or Rebuild commands, or before running the application, or when a Just In Time (JIT) compile takes place at the start of each top-level task or test.
Compiler errors are non-recoverable and fatal. Compiler errors will be listed in the Build Log and in the Status bar at the bottom of the main window.
For more information on individual compiler errors by error number, see Compiler Errors.
Run-time errors can occur when you run the compiled application code.
The two classes of run-time errors are:
Non-recoverable run-time errors
Recoverable run-time errors
For more information on individual run-time errors by error number, see Run-Time Errors.
Examples of causes of run-time errors are:
An instrument is not responding.
A COM object method or property failed.
Any run-time errors that are not handled by user-provided error handler code in the application display a default error handler dialog box with different options based on whether the run-time error is recoverable or non-recoverable. The default error handler dialog box shows the error number, a short description, the line number where the error occurred, and options. At the same time, a code view window displays on top showing the statement causing the error, marked with an arrow.
For more information on the default error handler dialog box options, see Run-Time Errors.
If the error was corrected by internal error handling code, you will not see a default error handler dialog box.
These errors occurs when abnormal exception is generated forcing you to exit ATEasy development environment or your ATEasy created executable or DLL. These errors are normally trapped by Windows however ATEasy traps these errors to provide further information used to debug and correct the problem. The information is provided using the ATEasy Exception dialog and is also logged to the Windows Application Log that can be viewed from your Windows Computer Manager or Event viewer. The information can be send to Marvin Test Solutions to further analysis.
A non-recoverable run-time error displays a default error handler dialog box that allows you the option to either Abort or Pause the application.
A special category of non-recoverable run-time error is the Just In Time (JIT) compilation error, which produces a special run-time error message. The message displays as run-time error # 499. You are only allowed the option to Abort the application. As with all compiler errors, a code view window displays on top showing the statement causing the error, marked with an arrow.
Note: In JIT compiling, the compilation of each top-level task is delayed until just before the task begins. This reduces the amount of code to be compiled and the time before execution begins.
Recoverable run-time errors mainly occur within I/O Tables, on the failure of a Trigger, Send, or Receive operation. They also occur within the Winsock interface, if a Send is attempted to an unspecified or invalid remote host or port.
A recoverable error displays a default error handler dialog box that allows you the option to Ignore, Retry, Abort, or Pause the application. You can retry or ignore the operation that causes a recoverable error.
Ways of handling recoverable run-time errors in your code include error handling via the OnError() event and try...catch blocks, which are discussed below.
You can include ATEasy's error handling code in your applications. The order in which error-handling code is executed is by calling:
If all the active try-catch blocks have been checked without finding a Catch statement which matches the error, then the module OnError events are called in a specified order. If the module in which the error occurred has an OnError Event, then that OnError event is called first. Any remaining module OnError events are called in the following order:
Drivers, from last to first
System