|
ColdFusion
Handling Errors Through the Application Framework
| |
The ColdFusion CFERROR tag allows you to use a custom error page to catch two types of errors: validation and request. You need a CFERROR tag and corresponding custom error template for each. The best place to put CFERROR tags is in Application.cfm so that they are included in all pages in the application.
Validation errors: ColdFusion has custom form tags which generate validation errors when a user has improperly submitted a form. A CFERROR tag with TYPE="VALIDATION" specifies the relative path of your custom error page file for validation errors.
Request errors occur during the normal processing of a ColdFusion template as a result of misspelled variable names, nonexistence of include files, etc. A CFERROR tag with TYPE="REQUEST" specifies the relative path of your custom error page file for request errors.
ColdFusion provides a set of error variables applicable to either validation or request errors that you can access in your error templates. The error templates cannot use any CFML tags, only HTML, but you can place references to the error variables as if they were inside CFOUTPUT tags. Note that handling errors this way aborts the processing of the template where the problem occurred. In the case of a Validation error, your custom page would contain a link back to the original page to try again.
One of the problems with using CFERROR tags and custom error templates is that
because you cannot incorporate any ColdFusion code you cannot log any of the
error information into a database or automatically send an informative email
to the administrator. A workaround is to have the error template store the
error variables in a form and then use a JavaScript event command to submit
the form to a second error template which can use CFML to log the error
variables into a database, send an email or whatever you need. To make
this work, you need to modify your Application.cfm template to disable
error handling for your error templates themselves. Determine the current
template path by using
CFSET PATH=GETDIRECTORYFROMPATH
(#CGI.CF_TEMPLATE_PATH#)
and then put the CFERROR tags inside a CFIF tag that checks that
CGI.CF_TEMPLATE_PATH is not equal to #path#your_error_template.cfm.
|
Working With Customized Exception Handling
| |
Since version 4, ColdFusion has provided a more structured way of handling errors within ColdFusion templates without necessarily aborting the processing of the template as CFERROR does
You enclose the code you want checked for errors within CFTRY tags. You can enclose an entire template or just a section of code. Just before the end CFTRY tag you include one or more CFCATCH tags. The opening CFCATCH tag specifies the type of error it will handle. Inside the CFCATCH tags you place all the CFML it takes to handle that error. Unless your code includes a command to abort the template, processing continues on following the closing CFTRY tag.
Error types not covered by corresponding CFCATCH tags will be processed by standard ColdFusion error processing, which will be handled by a CFERROR tag if you have one in effect.
For testing or validation purposes you can generate your own exceptions with the CFTHROW tag and create CFCATCH tags to handle them.
|
Debugging
| |
The ColdFusion Administrator has settings that can provide important debugging information for every application page requested by a browser. When enabled, debugging output is shown in a block following normal page output.
You can view the parameters and CGI environment variables for an individual application page without turning on the global debug settings in the ColdFusion Administrator. Simply append the parameter "mode=debug" to the end of the URL
www.myserver.com/cfdocs/test.cfm?mode=debug
You can view debug information for an individual query by putting the DEBUG attribute into the opening CFQUERY tag:
<CFQUERY NAME="TestQuery" DATASOURCE="CompanyInfo" DEBUG>
SELECT * FROM TestTable
</CFQUERY>
When this query runs, it places the debug information into the output page where the query is placed.
|
ASP
ASP’s normal response to errors is to display an error message. The message may
or may not be enough to help you, the developer, to find out what caused the
error, but either way you don’t want you end users to be subjected to such
things. The solution to that is to put <% On Error Resume Next %> at the
top of the page, but if that’s all you do then no one will ever have any
inkling that an error occurred.
The Err object holds information about one error. One database operation can
produce multiple errors or warnings. The ADO Connection object has a collection
called Errors which provides information about multiple errors as they occur.
Each error is placed in its own Error object in the Errors collection. You
can access this collection and its associated objects to find all the errors
that a statement caused.
The best way to make use of the Err object or Errors collection is to create
a file that you can include in all pages, and in that file write your own
routine to handle errors. Ideally, it will display a soothingly expressed
error message to the viewer and email an administrative person with the
script name and error number. You’ll access this routine within each page
by testing for Err.number other than zero after all error-prone activity
such as database access. Here is an article that provides just such a file.
http://4guysfromrolla.com/webtech/060399-1.2.shtml
When you know there’s a bug in a page and you want more information, a good
approach is to temporarily include a file that contains code to display the
contents of the collection you are concerned with, e.g., QueryString, Form,
Cookies, Server Variables, Application Variables, Session Variables,
ClientCertificate. Here’s an article that provides such a file.
http://4guysfromrolla.com/webtech/021099-1.shtml
PHP
By default, PHP responds to programming errors by providing standard error messages with information such as the file name, function and line number where execution halted. In order to provide a more user-friendly result when the program fails during an end user’s session you must deal with potential problems explicitly. For example, you would code such error-prone functions as connecting to the database or executing a query within an "if" statement that tests for an invalid result and takes direct action. Not everything returns an error, however, for example, if an include statement does not find the file to be included. In this particular case, the strategy would be to use the define() function to explicitly check whether it exists before including it.
PHP provides the error_log() function for logging any errors which occur, but there is not a function to trap every possible error for default custom handling when the above tactics fail to catch it.
|
gallery
