If the debug options are disabled in the settings, no debugger will be shown, and the elementary action is finished with an Error-verdict.
Typical situations in which the debugger pops up are Division-by-Zero, Index-Bounds-Errors, File-Not-Found-Errors etc. However, the debugger is also opened if you put a breakpoint (or a programmed halt-call) into your elementary block's code.
This is an expert tool, useful to coders only.
Aborting vs. Terminating vs. Proceeding
If you are not interested in further investigation of the error, simply press the "Abort" button to finish the current activity (with an Error-verdict).
Avoid the "Terminate" button, as this will kill the underlying thread. This should be only used as a last chance, when an error is reported again and again. Often termination will close the underlying thread's window, which may be the expecco-window. Always first try to "Abort" a few times before terminating.
Some errors are proceedable, if they are considered to be non-severe. For example a File-Not-Found" error might be proceedable and the program would then continue with a nil file handle (which may of course lead to future errors, if the nil-handle is ever used for I/O operations). The proceedability depends on the way the error was signalled and is usually a choice of the programmer (i.e. whether the code which uses a file is prepared to deal with a nil handle). In almost all situations, they are not.
Single stepping within the elementary code is possible via the "Next", "Step" and "Send" buttons. "Next" does linewise single stepping, "Step" performs the next call inside the selected function (both do not step into called functions), and "Send" goes into called functions.
All of these three buttons always operate within the currently selected function (in the top list). Thus, you don not have to step through all the internal low-level code; just select a frame higher in the calling hierarchy, and step there.
The popup-menu offers another useful function "Step until Cursor Line"
What is Shown by the Debugger
The debugger displays the state of the suspended program in multiple panes. The top pane shows a walkback (calling chain), presenting the calling functions. Click to select one of the callers to see how and where it called the function in error.
Once selected, the function's source code and current execution line number is shown in the middle pane.
Notice, that you should have checked the "Install Source Code" toggle in the initial installation; otherwise, the debugger will not be able to show the source code. If you did not, please repeat the installation process, checking the "Install Source Code" toggle.
The lower pane displays the contents of the receiving object (i.e. the object of which a function was called) on the left, and call-arguments plus local variables of the function. These are standard inspector windows, so they allow code evaluation (doIts) and following references by double click on a selected item.
Programming in the Debugger
One of the unique features of expecco is the ability to change the code in the debugger and proceed. If your elementary code block contains an error, you can interactively write new code in the debugger, try it via "DoIt"/"PrintIt" and finally "Accept" (i.e. install your changed code). When the block is invoked the next time, the new code will be executed. If you want to repeat the block's invocation with the new code immediately, press the "Resend" button. This will restart the selected function from the start (you can also move up/down in the calling hierarchy of the walkback and restart other functions). Due to the way code is compiled and the amount of debugging information compiled into the system, some functions are not restartable. If this is the case, select one further up, and restart that one. But be careful to not navigate beyond the caller of your elementary block, otherwise you may end up restarting the whole test-suite or test-case.
Things You Cannot Change
Expecco protects itself from modifications done to itself. So you cannot modify code of the expecco application. Actually, since only the source code of the basic framework classes, but not the expecco application classes is deployed, you will not even be able to see the internals of the expecco system. This is not a bug but done by purpose.
Entering the Debugger via the Interrupt Key
If the system seems to no longer react (or is executing an endless loop), you should normally be able to stop/pause the execution via the execution control buttons. In very rare situations, these may seem to not react, and the systems seems frozen. This happens if a system lock (semaphore) is kept and not freed, or if a high priority process executes an endless loop. Although we take good care to avoid/find/and fix such situations, and they are really very very rare, you can still interrupt the system with the interrupt key (CTRL-., CMD-.or INTR/PAUSE , depending on your operating system and keyboard layout) and force a debugger to be opened and the current activity to be suspended or aborted.
Depending on the operating system used (Linux vs. MS Windows vs. macOS), some operations cannot be interrupted. For example, on MS Windows, some OS-API calls are uninterruptable.
Back to Online Documentation.