Export (0) Print
Expand All

Run-Time Errors

Microsoft Dynamics Nav 2009

Run-time errors occur when the program is executed. These errors are not detected by the compiler, because the code is syntactically correct.

Run-Time Errors

An example of a run-time error is a statement that causes division by zero. In the following statement, the syntax is correct, but the statement may cause a division by zero error if the variable Second_number is assigned a value of 0:

Ratio := First_number / Second_number;

The common trait of these errors is that the code works correctly in many situations, but fails in others. The risk is that since there is nothing syntactically wrong with the code, the error could occur when the program is already in use. Unless you handle the run-time error in your code, default messages will appear.

Run-Time Errors and Data Consistency

There may be instances when run-time errors can compromise the integrity of the database. For example, if some fields are updated in a trigger and a run-time error occurs while other fields have not been updated. When a trigger is entered, a write transaction begins. If a run-time error occurs inside the trigger, the write transaction is rolled back and the execution of the trigger is terminated.

How to Avoid Run-Time Errors

The following guidelines show how to avoid run-time errors. These are only guidelines, as the conditions under which run-time errors occur are dependent on the context of your application.

If, for example, you use the GET function to locate a record, you must be prepared handle the possibility that a run-time error can occur if there are situations where no record is found. If you are certain that the specific context precludes this situation, you can omit handling a possible run-time error. (The context could be that the existence of a record is verified before the GET function is used.)

There are two categories of run-time errors:

  • Errors that are related to the use of data types

  • Errors that occur if a function does not succeed in doing what it is supposed to do

Division by zero does not fit into either of these categories, but it has been placed in the first one.

You can only prevent some errors (mainly related to data types) from occurring. Other errors cannot always be avoided, but you can write code that shields the user from the error. Instead of the default error handling (which displays a message, closes the form that was active when the error occurred, and rolls back any changes to the database), you can write an error handler that, for example, gives the user an opportunity to correct the input that caused the error. This error will display a message that explains why the error occurred.

Data Type-Related Errors

The easiest way to avoid data type-related errors is to use the correct data types. Errors like the type conversion error in the previous example and overflow errors can be avoided by using the correct data types.

A division by zero error can be avoided in several ways, depending upon the context where the code fragment is used. If the user enters the denominator (the Second_number variable) in a text box immediately before the evaluation of the statement, you could test the value of Second_number before performing the division, and reject a value of 0 (zero):

IF Second_number <> 0 THEN

Ratio := First_number / Second_number

ELSE

MESSAGE('Second_number must not be 0');

If Second_number is a field in a database table, and it should never be allowed to have a value of 0 (zero), the best place to perform this check is in the OnValidate trigger of the field. This enables you to ensure that a value of 0 (zero) can never be entered in the field.

Other Run-time Errors

Any function that fails to accomplish what it is intended to do can cause a run-time error. A good example is the GET function, which is used to locate a record in a table according to criteria that you specify.

The syntax of the GET function is:

[Ok :=] Record.GET([Value1], [Value2 ],...)

The return value of the function is Ok, a Boolean. If a record is found, the return value is TRUE; otherwise, it is FALSE. This return value can be ignored, as indicated by the square brackets. If it is ignored and the requested record cannot be found, a run-time error occurs and a system-generated error message is displayed. However, if you test the return value and a run-time error does not occur, it is assumed that you handle the condition yourself.

The C/SIDE Reference Guide provides information about how other functions handle errors. You can also look at the syntax description in the Symbol Menu, to see if the function returns a value called Ok. If it does, consult the C/SIDE Reference Guide to see which functions return a Boolean for other reasons than those described here. For example, the ASCENDING function can be used to check the sort order of a table. In this case, it returns TRUE if the sort order is ascending, and FALSE if it is descending.

If you use the return value in either of the following examples, you can shield the user from a run-time error.

Example 1:

IF NOT Customer.GET("No.") THEN

Customer.INIT;

Example 2:

IF NOT Customer.GET("No.") THEN

BEGIN

MESSAGE('Customer %1 not found', "No.");

EXIT;

END;

In the first example, if a Customer record with the given number (No.) cannot be retrieved, an (empty) record is initialized. In the second example, the user is notified that the record cannot be found and the trigger from where the GET function was called is exited. These examples are only general guidelines. You must consider how to handle situations like these in the context of your own application.

Finding and Correcting Run-time Errors

To determine the cause of a run-time error, you need the exact description of the sequence of events that led to the error. The sequence of events should include the following:

  • What the user was doing at the time of the error

  • What values the user entered

  • What record caused the error

If the error was caused by a calculation that failed to check whether a division by zero was about to be carried out, you should be able to find the statement that led to the error. However, if the circumstances that led to the error are more complicated, and you cannot determine the exact location of the error, you can use the debugger.

See Also

Community Additions

ADD
Show:
© 2014 Microsoft