Error management and tracing/logging Foundation

In this chapter, you will learn how CXP deals with compile/link time and runtime errors, and how CXP can assist you in fixing them.

Also, you will see how tracing/logging can be used to answer typical programming questions which you are likely to encounter when working with web applications.

The CXP infrastructure knows about different error types. Each error type is demonstrated by the Error-handling sample on the intro tab. Clicking on the sample's name will show instructions and more information abouth the example in a second browser window or tab.

Compiler error

The following steps provoke a typical error that is detected by the compiler.

Open the file errors.cxp in the folder <wwwroot>/samples with a text editor.

Modify the first line in the following code section by replacing #if 0 with #if 1.

00: // compile 
01: #if 0 
02:   SD SD 
03:   FOR x:=1 TO 10 
04:     ? "TaTa" 
05:   ENDIF 
06: #endif 

Save the file errors.cxp.

In the web browser, click on the heading Error-handling. This will reload the errors.cxp page.

Explanation:

By replacing the #if 0 preprocessor statement with #if 1, subsequent lines are made visible to the compiler. However, line #2 does not contain a valid Xbase++ expression which causes the compiler to raise an error. In addition, the ENDIF statement in line #5 has no matching IF statement. As a result, a descriptive error page including detailed information about the nature of the errors is provided by the CXP infrastructure.

Fix the compiler error as follows:

Comment out line #2.

Replace ENDIF with NEXT in line #05.

Linker error

The CXP infrastructure is also able to detect errors which are raised by the linker. The following procedure demonstrates this type of error.

Modify the first line in the following code section by replacing #if 0 with #if 1.

00: // link 
01: #if 0 
02:   TaTa() 
03: #endif 

Save the file errors.cxp.

In the web browser, click on the heading Error-handling. This will again reload the errors.cxp page.

Explanation:

The line #2 contains a TaTa() function call. As this function is not defined, the symbol TaTa cannot be resolved by the linker. Therefore, the CXP infrastructure aborts the build and provides you with information about the problem in an error page.

Fix the linker error as follows:

Comment out line #2

Runtime error

Some errors cannot be detected by the CXP build environment. These errors are raised while the CXP page is executed and therefore are named runtime errors. Follow the instructions below to provoke a runtime error and see how the CXP infrastructure deals with it.

Modify the first line in the following code section by replacing #if 0 with #if 1.

00: // runtime error 
01: #if 0 
02:   ? test test 
03: #endif 

Save the file errors.cxp

In the web browser, click the heading Error-handling to force a reload of the CXP page.

Explanation:

In line #2 the symbol test is accessed. Because test cannot be resolved by the CXP runtime environment, a descriptive error page is returned from the CXP infrastructure.

Fix the runtime error as follows:

Correct the runtime error in line #2 by adding string delimiters to form a legal character expression.

CXP comes with integrated logging facilities. The CxpAbstractPage class from which all of your CXP pages are derived from provides a :trace()method used to output data to a log file.

All CXP-specific log files are located in \ProgramData\Alaska Software\logfiles\cxp20\. CXP creates one log file per day. An exemplary log entry is shown below:

2018-07-30 13:48:37.587 23348:001 [info] Cxp-request-start(10) cpu(3) 
2018-07-30 13:48:37.588 23348:001 [info] Global-Config-Loaded: c:\inetpub\wwwroot\global.config 
2018-07-30 13:48:37.593 23348:001 [info] CxpApplication:FindClassObject(URL:/index.cxp) 
2018-07-30 13:48:37.615 23348:001 [info] Cxp-request-end Elapsed(28ms) 

The log output above is the minimum output of a single CXP page execution if tracing is disabled. The first line shows the number of requests previously serviced by this cxp-worker process as well as the the CPU the worker is currently using. The next log entry specifies the global config used for the CXP page execution followed by the CXP page URL. Finally, the time required for processing the page is written to the log file. The log file format used and its columns are described below:

Tracing is the ability of the cxp-worker to document via logging the process of receiving HTTP requests and processing the corresponding CXP page. The more complex your web application is, the more helpful the logging information becomes since it provides detailed information about the individual steps performed for processing your requests.

It is considered good practice to use the tracing capability for documenting the workflow inside your web application. By default, tracing is disabled. To enable tracing, add the trace attribute to the page directive of your CXP page as shown below:

<%#page layout="/site.layout" trace="yes"%> 
... 

Alternatively, you can manage tracing at a global level via the buildmanager settings in the global.config file.

<buildmanager> 
<behaviour trace="yes" clean="no"/> 
</buildmanager>