4D v16.3Compilation diagnostic aids |
||
|
4D v16.3
Compilation diagnostic aids
Compilation diagnostic aids
There are three types of aids for the analysis and correction of databases:
Note: Significant assistance is also provided for the typing of variables by the automatic compiler methods — see Generate Typing. The symbol file is a text type document whose length will depend on the size of your databases. By default, this file is not generated at the time of the compilation. To do so, you must check the corresponding option in the Database Settings (see Compilation options). When it is generated, the file is placed in the folder containing the database structure and is automatically named DatabaseName_symbols.txt. The symbol file is displayed as follows when it is opened using a text editor: The header displays the name of the database and the date and time of the document creation. The document is divided into four parts:
These two lists are divided into four columns:
Note: When compiling, the compiler cannot determine in which process a given process variable is used. A process variable can have a different value in each process. Consequently, all process variables are systematically duplicated as each new process is launched: it is thus advisable to watch out for the amount of memory that they will take up. Also, keep in mind that the space for process variables is not related to the stack size for the process. The list of local variables is sorted by database method, project method, trigger (table method), form method, and object method, in the same order as in 4D. This list is divided into three columns:
A complete list of your database and project methods is given at the end of the file with:
This information appears as follows: Procedure or Function <Method name>(parameter data types):result data type, number of calls, Thread Safe or Thread Unsafe You can choose whether or not to generate an error file during compilation using an option located in the Database Settings (see Compilation options). When it is generated, the error file is automatically named DatabaseName_errors.xml and is created next to the structure file of the database. Although the errors can be accessed directly via the compiler window, it can be useful to have an error file that can be transmitted from one machine to another, particularly in the case of several different developers working together in a client-server environment. The error file is generated in XML format in order to facilitate automatic parsing of its contents. It also allows the creation of customized error display interfaces. The length of the error file depends on the number of errors and warnings issued by the compiler. When you open an error file using a text editor, it looks like this: The structure of the error file is as follows:
An error file may contain three types of messages:
These errors are displayed in context — the line in which they were found — with an explanation. The compiler reports this type of error when it encounters an expression in which it sees an inconsistency related to data type or syntax. In the compiler window, double–click on each error detected in order to open the method concerned directly in the 4D Method editor with the line containing the error highlighted. The list of syntax/typing diagnostic errors is found in the Error messages section of the 4D Language Reference manual. These are errors that make it impossible to compile the database. There are two cases in which the compiler reports a general error:
General errors are so named because they cannot be linked to any specific method. In the first case, the compiler could not perform a specified typing anywhere in the database. In the second, it was unable to decide whether to associate a given name with one object rather than with another. The list of general errors is found in the Error messages section of the 4D Language Reference manual. Warnings are not errors. Warnings do not prevent the database from being compiled; they simply point out potential code errors. In the compiler window, warnings appear in italics. Double–click on each warning to open the method concerned directly in the 4D Method editor with the line concerned by the warning highlighted. The list of warnings is found in the Warnings section of the 4D Language Reference manual. You can disable certain warnings (see Disabling warnings during compilation). Range checking is checked by default in the Database Settings (see Compilation options). Whereas all the other options operate during the compilation process, range checking begins when you run the compiled database. That is, range checking messages only appear when your compiled database is running. Range checking provides additional analysis with respect to the quest for logical and syntactical consistency which normally characterizes a compiler. During range checking, the compiler poses the following question: “Considering what you have requested, will the result that I am likely to obtain surprise you?”. Range checking is an “in situ” controller; it evaluates the status of objects in the database at a given time. Here is how range checking works. Suppose that you declared the array MyArray as Text. The number of elements in MyArray may vary depending on the current method. If you want to assign the value “Hello” to element 5 of MyArray, you would write: MyArray{5}:="Hello" If MyArray has five or more elements at that time, everything is fine. Assignment proceeds normally. However, if MyArray has less than five elements at that time, your assignment no longer makes sense. A situation like this cannot be detected at the time of compilation since it presupposes the execution of the methods. The compiler would not know the circumstance in which this method is called. Only range checking enables you to monitor what is actually happening while your database is in use. In the above example, the compiler would display an execution error from within 4D. It is easy to see why range checking is especially valuable when arrays, pointers, and strings of characters are being processed. The messages sent by the compiler when you request range checking are listed in the Range-checking messages section of the 4D Language Reference manual. Even when range checking has been enabled, there may be some cases where you prefer that it not be applied to certain parts of code that are considered to be reliable. More particularly, in the case of loops that are repeated a great number of times, and when running the compiled database on older machines, range checking can significantly slow down processing. Insofar as you have the certitude that the code concerned is reliable and cannot cause system errors, you can disable range checking locally. To do this, you must surround the code to be excluded from range checking with the special comments //%R- and //%R+. The //%R- comment disables range checking and //%R+ enables it again: ... //Range checking is enabled Note: This mechanism will only operate when range checking is enabled. Suppose you notice anomalies when running your databases. Before you start speculating about the possible sources of these problems, remember the assistance provided by the compiler. Potential anomalies are:
|
PROPERTIES
Product: 4D
HISTORY
Modified: 4D v15 R5 TAGS %R, warning, Contrôle d'exécution ARTICLE USAGE
4D Design Reference ( 4D v16) |