CUT_ERR Overview
Copyright © Dundas Software Ltd. 1996-1999, All Rights Reserved
Dependencies and Related Files
CUT_ERR can be thought of as a sort of 'namespace' class which organizes the declaration of error codes and their associated error text. The motivation for the class was to move error code definitions out of the realm of the preprocessor and into the code itself, so that values would be visible during debug sessions, etc.
The class uses an enumeration to define error codes that will be used for other classes in the library. These could have been declared as const members, but not all compilers support this feature.
The constructor, destructor, copy constructor and assignment operator are declared as private members. This class cannot be instantiated or used as a base class.
Along with the enumeration of errorcodes, two static public methods are declared. GetErrorString() allows the user to retrieve a text description of the error. GetSocketError() can be used during development to retrieve the error associated with a winsock API call that has returned SOCKET_ERROR.
GetErrorString calls the static private method InitErrorStrings() the first time it is called. InitErrorStrings() then initializes an array of string constants.
Adding New Codes
The list of errors available (in uterr.h) is easily extended by adding the new constant (e.g. UTE_THE_ERROR_DUNDAS_FORGOT) to the CUT_ERROR_CONSTANTS enumeration and then adding a line of code to the initialization method InitErrorStrings. You might like to leave the core code alone, so we've provided a mechanism for extending the errors without modifying uterr.h.
An additional header 'UTExtErr.h' can be found in the Include directory. You can use this file to insert new errorcodes and their corresponding text into the CUT_ERR enumeration. You can edit this file in place if you want to extend your new errors to all projects, or you can use it on a per-project basis by copying it to your project directory. (Make sure your project pre-processor additional includes contains ".\" so that this version is included from within uterr.h).
Inside UTExtErr.h you will find the following (commented) sample:
#ifndef _EXT_ERR_STRINGS
// Add your error constants here. See example below:
// UTE_DATABASE_CONNECT_ERROR,
// UTE_NOT_SUPPORTED,
#else
// Add your error string associations here. See example below:
// pStrings[UTE_DATABASE_CONNECT_ERROR] =_T("Database connection error.");
// pStrings[UTE_NOT_SUPPORTED] =_T("Operation is not supported.");
#endif
Add the mnemonic for your new code followed by a comma, and specify a string to be returned from GetErrorString().
Usage
While the enumerated 'constants' are available without the need for scoping, the static GetErrorString needs to be prefaced by the class name. (This is the 'namespace' aspect of the class.)
For example, to display all of the available errorcodes and their numeric value one could write:
for (int i = 0; i < CUT_MAX_ERROR; i++)
cout << i << ". " << CUT_ERR::GetErrorString(i) << endl;
This may be something you want to do in order to have a numeric reference for debugging. We don't explicitly assign values to the codes inside the enumeration, so you can not just refer to the header to see what 'error 43' means. Being able to call GetErrorString provides some compensation.
Many of the client and server classes that use these enumerations as return codes do so via a virtual OnError method which can be overridden or modified to trace error messages through the use of GetErrorString. In most cases we leave it up to you to implement this so that you can then select the appropriate output device.