UsersGuide:Chapter 12:Runtime Exception Errors

From Real Software Documentation

• User's Guide Table Of Contents
• Chapter 12: Contents

---

• Previous: Starting and Stopping Your Project
• Next: Profiling your Project

Contents 1 Runtime Exception Errors 1.1 Runtime Errors in Standalone Applications 1.2 Handling Runtime Errors 1.2.1 The Try Statement

Runtime Exception Errors

When you test your application in the IDE, Real Studio performs basic syntax checking and, if it finds a problem, it stops compilation and alerts you to the problem.

There are certain types of errors that can be detected only at runtime, (i.e., when the line of code that contains the problem is actually executed). This is because these errors depend on values that are not known until the code is running. An application containing a runtime error compiles without error and may even run without problems for a very long time before the lines of code containing the error are actually called.

But when these lines are executed, Real Studio has no choice but to stop execution. If you are testing the application in the IDE, the Code Editor will reappear and an error message will be shown below the line that contains the runtime error. An example runtime error message is shown below.

To find and fix all such errors via the Debugger, you should select the Break on Exceptions item in the Project menu. With Break on Exceptions on, the Debugger will appear when a runtime error is encountered while you are testing your application. However, the unhandled exception will cause the built (standalone) application to quit.

This error occurs when the value of the counter, i, reaches the value of nFonts. The programmer has forgotten that font numbering starts at zero rather than one; the loop should be from zero to FontCount-1. Until the value of nFonts is actually reached at runtime, the error cannot be detected. If the error is buried in an obscure method that is very rarely called, the application may survive many hours of testing without encountering the error.

As with syntax errors, the Tips bar contains the error message.

Runtime Errors in Standalone Applications

If the error occurs in a built application, Real Studio displays a generic message box that identifies the type of problem that it encountered. An example message box is shown below.

The application will quit when the end-user accepts the message box.

Handling Runtime Errors

Real Studio provides a way to detect and handle runtime errors that occur in standalone applications. There are several types of so-called runtime exceptions that you can detect in your code and handle. Please see the description of each Runtime Exception error in the Language Reference for more examples.

You can “catch” and handle runtime errors using the Try or Exception blocks. With either type of block, you can display a more informative message box that will help track down the problem.

Exception blocks always appear at the end of a method (not where you think the error might occur) because every line after the Exception line is considered part of the exception block.

When a block “catches” an exception error, the code in the Exception block runs, allowing you to obtain information on the location of the problem and the values that caused the error.

With an exception block, you can add code to your methods that handle the error in specific ways, depending on the type of error and the context in which it was encountered. This provides more control over the error handling process than the Break on Exceptions menu command.

In the Code Editor, the Exception line has the same level of indentation as the Sub or Function line. You can use Exception alone if you wish to handle any type of exception in the Exception block, as shown below:

The syntax of an Exception block is as follows:

Both errorParameter and errorType are optional; errorType cannot be used without errorParameter.

The example shown above is sufficient to prevent the application from quitting, but the message is not very informative because you don’t have a clue what type of exception occurred.

One way to test ErrorParameter is with an If statement in the Exception block:

For example, the runtime exception error shown below can be handled with the following exception handler.

When this method runs, it displays a message box such as shown below:

When the end user accepts this message box, the application does not quit.

Instead of using multiple If statements, you can also use multiple Exception blocks, each of which handles a different runtime exception type:

In case you fail to include an Exception block in the method in which the error occurs (or a method that calls the defective method), you have one last chance to “catch” runtime errors before they bring down a built application. This is in the UnhandledException event of the Application class. This event occurs if a runtime error occurs anywhere in the application that was not handled by an Exception block. This event is passed a parameter of type RuntimeException and you can write a function that handles the exception. For safety’s sake, you can write a generic routine that catches all runtime exceptions.

In this example, if the Action event shown here did not include an Exception block, you could catch the runtime error using the following function in an App class (a class derived from the Application class).

This method of handling runtime errors cannot provide the specific diagnostic feedback because it will receive all OutOfBoundsExceptions throughout the application.

The Try Statement

The Try statement is similar to the Exception statement. Exceptions that occur within the Try statement are caught by the Catch statement. It has the same syntax as the Exception statement. See the RuntimeException statement or the Runtime Errors theme for descriptions of each type of runtime error.

Unlike the Exception statement, Try statements can be nested. If a Try statement does not handle an exception or re-raises it, it can be handled by the next outermost Try statement, or by the Exception statement itself if there are no containing Try statements.

A Try statement can contain its own Finally statement. The code in the Finally statement will execute regardless of whether or not an exception was raised within the Try statement.

Here is this example, rewritten as a Try statement.

---

• Previous: Starting and Stopping Your Project
• Next: Profiling your Project