Since a script is a simple text file, you can type anything in it, even complete nonsense. But
also scripts that look fine can, and often will, behave differently than the programmer intended. In the simplest case, the compiler
shows you an error message. In less trivial cases, the error message happens when the script is running. The worst cases are code that gives no error message, but just does not do what it should, or even crashes or freezes.
Any programmer encounters all those issues all the time. Depending on what happens, the problem can be trivial to fix, or hard.
Write good code
The first step to avoid errors and bugs is good programming style - a style
that allows easy reading and understanding the code. Fortunately, strategy
scripts are normally not very long, use not many variables, and have a linear
structure. Some suggestions for avoiding bugs already when writing the script:
- Have a naming convention for variables and functions.
For instance, let variables begin with uppercase and functions with
lowercase letters, let series end with 's', and let variables that count
something begin with 'N' or 'Num'. The details of the convention do not
matter, as long as you stick to it.
- Divide the script into functions that are no longer
than about 10..20 lines of code. If a function is longer, delegate its tasks
to smaller functions whenever it makes sense.
- Keep similar things together. For instance, set up all
variables at one place, define all series at another place, open all trades
at a third place in the code.
- When functions open, create, or load something, always check for
nonzero the returned pointer or handle, and manage the case that
the requested file, trade, contract, or memory area was not found, not
opened, or not available.
- Make not only the look, but also the behavior of the script transparent.
Print any event in the log, such as any signal or condition
that affects opening or closing trades. This way you can understand at a
glance which variable values led to which trade decision in the backtest.
Error messages when compiling the script indicate simple syntax errors. Something is mistyped, or a bracket or semicolon is missing, or an object got the same name as a pre-defined function or variable (their names can be found in the include\functions.h and include\variables.h files). The script file and line in question is printed in the error message. This
makes those errors easy to identify and fix, even for a beginner.
More subtle errors cannot be detected by the compiler, but produce a message at runtime. Under error messages you'll find a list of all such errors and warnings, and their likely reasons. Messages related to opening and closing positions are listed under trading;
known issues with brokers are described on the related page (FXCM, IB, Oanda, MT4,
etc). The answers to many typical issues of script development can be found in the FAQ list.
If you see a runtime error message (like "Error 123: ....")
in the message window, but have no clue at which part of your code the problem
happens, the quickest way to find it is placing _POS()
statements before suspicious places. The parameter is then displayed at the end
of the error mesage. For instance, _POS(10) will add a
(10) at the end of all subsequent error messages, and
_POS("TEST") will add (TEST). You can remove
the statements when the error is fixed.
It gets more difficult when no error messages are displayed, but the script
just behaves wrong. Below you can find the usual methods for solving those problems. Beginners to programming are often not able to find the reason of the problem quickly. For getting external help, you have two options. Either subscribe a support ticket on the Download Page and ask us for help. We do not fix your script, but we'll show you the bug and help you to fix it yourself. Alternatively, post a question in the User Forum and ask other users for help. In both cases you'll need to upload your script so that we or they can look into it.
But normally you should learn to find and fix bugs in your code by yourself. Here are the usual steps when you encounter issues with your script:
If your script behaves badly - for instance, it trades too often, or not often enough, or at the wrong time - you must
debug it. Debugging strategy scripts is a special case of
program debugging since you're normally interested in the behaviour of a
variable or signal from bar to bar. You have to look into parts of the script that you suspect of wrong behavior. There are several methods to
observe the behavior of variables, either from code line to code line, or from
bar to bar, or during the whole test run:
- Single-step through parts of code, or
through loops, while observing variables. For this, place watch("!...",...) statements
with exclamation mark and with the variables to observe inside the loop or
behind suspicious commands.
- Single-step from bar to bar, using the
STEPWISE flag. Display suspicious variables or indicators,
either again with watch statements, or on the chart
that is drawn at any bar in this mode.
- Set the LOGFILE flag, and set Verbose to a high value, like 3 or 7. Use printf statements to print variables and other information to the log file. Run a test, open the .log file and examine the trades in detail. If the problem happens
only when training a script, use print(TO_FILE,...) for printing information to the training log.
- Plot the variables in question in a curve of the whole simulation. For instance, in order to check the overall behavior of a variable TradeSignal that determines when a trade is triggered, put this line in the script:
plot("TradeSignal", TradeSignal, NEW, RED);
They look more serious, but are normally easier to fix than bugs that just cause wrong behavior. You can encounter three types of crashes:
- Zorro terminates with a Windows error message (like "Runtime Error").
This is normally a crash in an external module, such as the broker API or some system component, caused by a software bug, a virus, a bad PC configuration, a faulty Windows library, running out of memory, or even a PC hardware problem. But in most cases it is a consequence of a preceding script crash.
- Zorro stops the script with a message like "Crash in script (some function name)".
90% of all crashes in beginner's scripts are due to confusing var and vars.
The other 4 popular crash reasons are: a numeric error (like taking the square root of a negative number,
or dividing by zero); exceeding the length of an array, string, or buffer;
wrongly assuming that a string or pointer returned by a function is nonzero;
or exceeding the stack size by using too large local arrays. If a crash
is caused by a memory error, Zorro must be restarted.
- Zorro freezes permanently and must be manually closed with the Task
Manager. Freezing is caused by a never-terminating while, do, or for loop in the script, or some endless recursion, such as a trade that opens further trades in its TMF.
Crashes are easy to fix when they happen regularly or always at the same bar or script position.
They are only hard to find when they happen irregularly and their reason is not immediately obvious. Zorro has a mechanism for detecting hard-to-find problems - the diagnostics mode. Here's a step by step instruction of how to use it:
- Set Verbose to 15 or 31 in the script. If you have no access to the script, alternatively start Zorro with the -diag command line option.
- Let Zorro run with the script in question until it crashes again. You'll now see a file ending with "..diag.txt" in the Log folder. This file is a 'black box' recorder containing the last 1000 internal events or printf or watch commands. The last line in the file is the last event immediately before the crash.
- For finding out where in your script the crash happened, place watch("#...")
or printf("#...") statements between the lines (such as watch("#1");, watch("#2"); and so on). You can then see
from the last such printed number in the diag.txt file after
which command the crash happened.
- An alternative method to find a crash position in a script is out-commenting parts of the script until it does not crash anymore. The crash reason can then usually be found in the last outcommented lines.
If you can't find the crash reason with the help of the diagnostics mode, or if you run into other trouble that you can't solve on your own, please report on the Zorro forum and post the content of the diag.txt file. This will allow other people to help you determining and fixing the problem.
► latest version online,