|
|
|
|
|
|
|
|
- Overview
- Declaring several processes of general exceptions
- Declaring the processes of general exceptions in the same process
- Declaring the exception processes in different processes
- Nesting the exception processes in different processes: managing the exception via a higher level
- Main remarks
- An exception process can only be used once
- Quality of WLanguage code for processing the exception
- Quality of the code following an exception process
- Special case
- Exception process and component
- Exception process and threads
- Functions for managing general exceptions
General exception mechanism
A process of general exception is available for all the components of the object with which it is associated. This exception process can be used as long as the object is available. A process of general exception can be declared in any process. After the execution of an exception process, the WLanguage code following the process is run. For example: - If the exception process is declared in the project initialization code, it is valid for any error that occurs in the project.
- If the exception process is declared in the declaration code of the global variables of a window, page or report, it is valid for any error that occurs in the window, in the page, in a window control, in a page control or in a procedure local to the window or to the page. This exception process is not valid anymore when the window or the page is closed.
- If the exception process is declared in any process, it is valid for any error that occurs in this process. This exception process will not be valid anymore once the process is completed. Therefore, an exception process declared in the click code of a button will only be valid in this process and in all the procedures called from this process.
Declaring several processes of general exceptions Declaring the processes of general exceptions in the same process The second exception process will replace the first exception process from the declaration of second exception process. Example: In the Example procedure, if an error occurs: - In <Code1>: no management of exceptions is enabled unless an exception procedure was defined in the calling code (in the current window or in the current page or in the project).
- In <Code 2>: the active exception process is <Process of Exception 1>.
- In <Code 3>: the active exception process is <Process of Exception 2>.
PROCEDURE Example() <"Code 1"> WHEN EXCEPTION <Process of Exception 1> END <"Code 2"> WHEN EXCEPTION <Process of Exception 2> END <"Code 3">
Declaring the exception processes in different processes If the exception processes are declared in embedded objects (project and window, project and page, window and control or page and control for example), the exception process of the smallest object hides the main exception process during the lifetime of this object. Example: If the following two exception processes are declared: - exception process A declared in the initialization code of a project,
- exception process B declared in the declaration code of global variables of a window or page.
For all the errors that occur in the window or in the page, the exception process B will be used and it will hide the exception process A. Nesting the exception processes in different processes: managing the exception via a higher level If the exception processes are declared in embedded objects (project and window, project and page, window and control or page and control for example), the error can be managed in the exception process of higher level. All you have to do is use the EXCEPTION keyword in the exception process. Example:
// Project initialization code
WHEN EXCEPTION
// Stop the application
EndProgram()
END
// Global procedure ControlValue
// Returns the value of the control or "" if the control does not exist
PROCEDURE ControlValue(ControlName)
WHEN EXCEPTION
// For the UnknownControl error, "" is returned
IF ExceptionInfo(errCode) = UnknownControl THEN RESULT ""
// For another error, the error manager of the project is called
EXCEPTION
END
An exception process can only be used once An exception process can only be used once. If a second exception occurs, the exception process will not be run. If an exception process of higher level exists, this exception process will be run. To re-enable an exception process once it has been used, call ExceptionEnable. Caution: this function must be used with great care. Quality of WLanguage code for processing the exception An exception process cannot be used inside a WLanguage exception process. We recommend that you check the quality of the code in the exception processes because any error will trigger the display of the standard window/page of the security mechanism of WLanguage. Quality of the code following an exception process After the execution of an exception process, the WLanguage code following the process is run. We recommend that you pay attention to the quality of this code (to avoid displaying an error message). Example: In the following code, {"Control1"}..Value = 5 triggers the exception process. At the end of the exception process, the same line of code is re-run: the exception was already processed and the security mechanism of WLanguage is triggered.
// Exception process
WHEN EXCEPTION
// Process to perform if an exception occurs
Trace("Error")
END
// Programming error: the Control1 control does not exist
{"Control1"}..Value = 5
To avoid this problem, at the end of the exception process, we advise you to: - Make sure that the problem is corrected and that it will not happen again.
- Use the RETURN and RESULT keywords to exit from the current process.
- Use SetFocusAndReturnToUserInput to give control back to the user.
 This feature is not available. - Use EndProgram to close the application.
A general exception process cannot be declared in compound statements such as: Exception process and component If a general exception process is performed both in the initialization code of the component and in the initialization code of the project containing the component, the exception process of the project will be run when an error occurs in one of the component elements. Exception process and threads If a general exception process is set in the project initialization code, it will be triggered if an exception occurs: - in the main thread,
- in a secondary thread started by ThreadExecute.
However, if the secondary thread triggers an exception, it will not be possible to find out its origin with ExceptionInfo in the project code. To find out the origin of an exception in a secondary thread, the exception process must be included in the secondary thread. Functions for managing general exceptions Functions specific to the management of exceptions can be used with the general exception processes:
This page is also available for…
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|