Strong Warnings Report
|Top Previous Next|
Targets: All except BP7 (partly)
This report generates warnings that help you identify especially severe errors. Those are errors that can cause runtime failures (“showstoppers”), or erroneous results in your application.
(Not relevant for BP7)
This section reports locations where properties are referenced in read/write methods, like for example:
These sorts of errors can cause infinite recursion.
This sections lists identifiers with ambiguous unit references.
Consider this example:
What will be the output from the program? In this case, it will be “Goodbye”, because the last unit listed in the uses clause will have precedence.
The reference to TheValue is ambiguous or unclear, so it will be listed in this report section. Consider what happens if originally only unit “A” was listed in the uses clause. Then the output would be “Hello”. If then maybe another programmer without any sense of danger will add “B” to the uses clause, the output will be changed.
You should prefix the reference, like “B.TheValue”, to avoid any uncertainty.
This sections lists subprograms that call themselves unconditionally. This will lead to infinite recursion and stack failure at runtime if the subprogram is called:
Consider this example:
Currently overload subprograms are not examined.
This sections lists locations in your code with an index error.
If the code had been instead "Arr" (an explicit value), the compiler would have halted on this line. But for a variable, it does not.
This section lists locations in your code where a pointer possibly is misused. For example a pointer that has been set to nil and further down in the code is dereferenced.
This section lists locations in your code with a possibly bad typecast. If you use the "as" operator, an exception will instead be raised. Otherwise there may be access violations and errors in a totally different code location, which is not very easy to track down.
In the example above, the last line could better be written (although still faulty!) as
Monkey := Banana as TAnimal;
This should result in an exception. But this is still preferable; instead of letting the code proceed resulting maybe in access violations later in a totally unrelated part of the code.
This section lists locations in your code where for loop has any of these conditions:
This section lists locations in your code where a call to a subprogram is made with bad parameters. The situation occurs when the called subprogram has an "out" parameter plus at least one another parameter. The identifier passed is used for both these parameters. Because an "out"-parameter is cleared in the called subprogram this will give unexpected results for reference-counted variables like strings and dynamic arrays.
This section lists generic interface types that declare a GUID:
The problem with this is that all generic types created from this interface, like IMyInterface<Integer> and IMyInterface<string> will share the same GUID.
This will cause type casting to malfunction.
This section lists out parameters that are read before set in the procedure.
Out parameters are not guaranteed to have a valid value when entering the function/procedure. They are just intended to be set.