Tour Sections

• Introduction
• Site Structure
• Page Assembly
• URL Handlers
• Multi-View Strings
• Authentication
• Database
• Error Handling
• Validation
• Config Data
• Logging
• EDP
• User Interface
• Formatters
• Images
• API Utilities
• Developer Tools

Online Reference

Tags:

fwpErr_removeCode

Types:

fwp_errorManager
fwp_validator

Configs:

strings_appErrors_{language}
strings_appValErrors_{language}

ToolKit Description

Error Handling and Debugging

The majority of runtime errors in an application come from three sources: coding bugs, resource errors (files, databases, etc), and user input validation errors. The PageBlocks framework uses one error management system to handle the coding bugs and resource errors (referred to as the error management system or error manager), and a separate system for the user input validations (validation system). This section focuses on the former.

The error management system integrates error definition, trapping, reporting, logging, and administrative e-mail alerts.

PageBlocks custom tags and types are coded with liberal error detection to maximize site reliability and smooth user experience should application level or framework level problems occur. The programmer can tap into and expand the error management system with minimal coding to include application-specific scenarios and error messages.

Simple to Use and Expandable

There are two key steps in using the error management system. First, the programmer constructs error detection [if] containers. If an error is detected, the else clause is used to add an error code and supplemental string to the error manager. The error code will often be one of the many prewritten pageblocks framework error codes for which responses and messages are already constructed.

if: (condition to meet);
    // proceed with application logic code
else;
    $fw_error->(insert: '5XXX' = 'comment or info to pass to error manager');
/if;

The second step is the inclusion of an error message into the application display. The framework can be set to automatically display error messages, or set to allow the developer to control exactly where that is done using a simple command of $fw_error->'errorMsgs' which will insert preformatted HTML strings. If an application-specific error code is needed, the programmer can easily add to the error code library. Leveraging the Multi-View Strings system, all error messages can be available in multiple languages and multiple versions suited to display devices or other variations.

Errors can also be proactively suppressed on an individual basis. If a routine expects a certain error is a possibility and needs to block the error manager's interruption, this is possible. The error is trapped then removed rather than suppressed upfront. This way the application can detect if a specific error occured, then remove the error from the $fw_error array an either ignore it or even substitute it.

The page assembly framework's blockLoader will automatically test the status of errors after loading each logic and content source, and invoke the error manager if necessary. Each page block is handled independently to allow those not reporting errors to fulfill their processing. This also allows error messages to be reported in the block in which the error actually occurred.

The $fw_error->'errorMsgs' content is built for each page block then handed off to a block specific variable to be displayed for user feedback (thus preventing each block from repetitive error message display). The pre-built message can be handled manually by the developer, or automatically by the framework.

Integrates Configurable User Email Support Links

The error management system integrates the presentation of support email links which allow users to send emails with further description of the error or events leading up to it. Messages automatically include an error log reference for administrators to reference. No source code or datasource information is displayed in error messages to prevent security risks, but such error details are logged.

Integrates Admin Email Alerts and Logging

Errors are rated with a severity level. A configuration variable is compared to determine whether the automated admin email alert system should be invoked for the error. There is a similar system to govern error logging.

Integrated Debugging

Supporting utilities are used to aid in debugging with an organized display of all variables at the end of each page, a timer to track how long specific tags and code segments take to process, and a tag tracer that can be used to build a sequence of exactly what code points have been processed, and what variable states are at those points. Many of the framework tags and types already integrate these tools.

Configuration parameters allow for the debug system to be enabled/disabled with a flag. Additionally, qualified IP addresses are explicitly listed to determine who sees debugging output. This allows the developer to turn debugging on and see variable status and other embedded messages, while general users see only the regular site content.