error scenerio handling

[hrishi321]

Hi I need to get enlightten with a concept in C++/vc++ designing.... This is an general question...may be more pertaining to design mechanism of any project I am trying to find out a good way to or standard method or any standard way to handle all the errro scenerio in a project? To be more specific, I am doing a project on a protocol analyser....Taking an aaccount of any kind of protocol, what are the good way of handling errors for the same...so that its more scalable,(means we can add more error cases or test cases later easily) May be an header file where all errrors will be saved as define primitive and handle all of them in a function....Or any good kind of mechanism... Please enlighten me with the same thanks in advance

[Lost User]

Use Exceptions[^] for all error situations.

txtspeak is the realm of 9 year old children, not developers. Christian Graus

[Jonathan Davies]

From experience I've settled on three classes: 1.CMessage: containing the description of an error, though a message doesn't have to describe just an error - "Application started" and "Application stopped", for example, can be included alongside "Widgit X fell over". Initially I used a .h file for this but migrated to using a .mc file as well, the .mc being compiled to produce a .rc resource file. 2.CEventLog: containing some means of logging a message. I started logging to a .txt file, moved to .html and now log to the Windows Event Log via the ReportEvent [^] function. 3.CExError which can be thrown and has a constructor which takes the error information and logs it. The most productive tactic by far I found was to ensure the file and line numbers where the error occurred were included in the message by using macros such as: #define AT __FILE__ ":" TOSTRING(__LINE__) Importantly I found this was a maintainable and expandable (relatively easy to add or edit messages) strategy which: 1. Didn't obscure the actual point of the code (too much) with line after line of error handling. 2. Completely hid away logging of errors in the CExError constructor, 3. Moved away (to the catch block) the point at which any code written to recover needed to go. So the actual code ended looking something like:

...
void someclass::somefunction(...)
{
try
{

    if(!AttemptSomething(param1, param2)
    {
        throw CExError(MESSAGE\_ID\_1, "Context info", AT);
    }

    if(!AttemptSomethingelse(param1, param2)
    {
        throw CExError(MESSAGE\_ID\_2, "Context info", AT);
    }
}
catch(CExError& err)
{
    //Decide what to do about any error here, such as:
    if(MESSAGE\_ID\_2 == err.MessageID)
    {
        MessageBox(err.Message);
    }
}
return;

}

...