Web Connection 5.0 introduces a new Error management mechanism that is a bit more flexible and relies on TRY/CATCH exception handling. This new mechanism is more consistent and removes one potential problem issue related to the RETURN TO command in Visual FoxPro and the need to bracket Error methods with #IF define blocks. All of that is gone in favor of a simpler event based error mechanism that can simply be overridden in your code.

DEBUGMODE Flag - Gone

The first change is the removal of the DEBUGMODE flag. This flag was used internally by Web Connection to turn error handling on and off. Primarily it served to bracket error methods in wwServer, wwProcess and your wwProcess subclasses.

The DEBUGMODE flag is replaced primarily by the Server.lDebugMode flag now. This flag is now dynamic and can be changed in your appMain.ini file or even dynamically at runtime on the Server Status form.

Action Item:
You should check all of your code and find any DEBUGMODE usage. Especially check your custom wwProcess subclasses and make sure that there aren't any DEBUGMODE flags. If they wrap Error Methods see the next section on how to change your code.

Custom wwProcess Error Methods

Due to the changes to error handling Error methods should no longer be used in your custom wwProcess classes. If you have Error methods in your Process classes, instead change them to the following signature:

FUNCTION OnError(loException as Exception)
* ... your custom error code here
ENDFUNC

This method serves exactly the same functionality as the old Error method did, but as you can see it doesn't receive three parameters, but rather a FoxPro Exception object. Errors are caught in a TRY/CATCH as part of the Process class' Process() method and wrapped around the RouteRequest() method. This captures any error in your code and fires the OnError() method on your wwProcess subclass.

Keep in mind that overriding OnError is optional. The most common scenario is overriding how the error message is displayed and you can override that instead by overriding the ErrorMsg() function.

But if you need to explicitly manage your errors here's the default OnError implementation that you can emulate:

FUNCTION OnError(loException as Exception)

*** Shut down this request with an error page - SAFE MESSAGE (doesn't rely on any objects)
THIS.ErrorMsg("Application Error",;
   "An application error occurred while processing the current page. We apologize for the inconvenience. " + ;
   "The error has been logged and forwarded to the site administrator and we are working on fixing this problem as soon as we can.<p>" + ;
   "<p align='center'><table cellpadding='5' border='0' background='whitesmoke' width='550' " +;
   "style='font-size:10pt;border-collapse:collapse;border-width:2px;border-style:solid;border-color:navy'>" + CRLF +;
   "<tr><td colspan='2' class='gridheader' align='left' style='font-weight:bold;color:cornsilk;background:navy'>Error Information:</th></tr>" + CRLF +;
   "<tr><td align='right' width='150'>Error Message:</td><td>"+ loException.Message + "</td></tr>" + CRLF +;
   "<tr><td align='right'>Error Number:</td><td> " + TRANSFORM(loException.ErrorNo) + "</td></tr>" +  CRLF +;
   "<tr><td align='right'>Running Method:</td><td> " + loException.Procedure + "</td></tr>"+CRLF+;
   "<tr><td align='right'>Current Code:</td><td> "+ loException.LineContents + "</td></tr>"+CRLF+;
   "<tr><td align='right'>Current Code Line:</td><td> " + TRANSFORM( loException.LineNo) + "</td></tr>"+ crlf +;
   "<tr><td align='right'>Exception Handled by:</td><td>" + THIS.CLASS + ".OnError()</td></tr></table></p>")

*** Log the Request
IF TYPE("THIS.oServer")="O" AND !ISNULL(THIS.oServer)
   this.LogError(loException)
ENDIF

*** We've completely handled the error!
RETURN .T.
ENDFUNC