deriving from std::exception and overiding what() to construct dynamic messages.

[vainstah]

Hello Guys and Galls,

To start off, I have reached the solution I was looking for, but I would like comments and feedback on the solution I have reached and tips/tricks on making it more elegant. I am not satisfied with the underlying machinery of the solution though.

I am an advanced C programmer and most do object-based programming in C++. Please do not reply to this article with references to basic material or obvious tips.

An overview to the problem I was trying to solve ; I have written a very complex plugin for a webserver and it shows some bugs only with live use (to be specific a ISAPI Filter for Microsoft IIS). I was not given the go ahead to do live debugging on the server and it might not have helped track the bug anyway. In order to catch it I have to improve the instrumentation of my software.

The error codes in the server (win32 API numeric error codes) are mostly converted into exceptions but the exceptions weren't intelligent in any way... they were all stand-alone and did not derive from a standard heirarchy. I need a standard heirarchy to maintain sanity and I need the debug messages to be dynamic. std::exception as a base class was the obvious choice (wish I hadn't gone down that route now :D ) .

I want the exceptions to have a title and a body and I would obviously want to generate the body at runtime.The problem is that the what() method signature from std::exception defines the what as a const method.

Getting arround the const restriction leads to a ton of fidley code, which I should say I cannot accept it has made me hate aspects of the C++ language and the std library, I certainly would have faired better implementing the following in straight C, however saying this I want my faith restored in the language and shown why I am being unfair. The following solution has taken me about 10 hours of refactoring.

The custom exception for my project requires the following semantics.

class CustomException
    : public SStreamException
{
public :
    CustomException(char * file_in,DWORD line_in)
        : SStreamException(file_in,line_in) {}
    virtual const char * getType() const
    {
        return "testing";
    }
    virtual void getBody(std::stringstream & body_in) const
    {
        body_in << "My Sexy Body";
    }
};

so the two methods getType() and getBody() are called from the what() method in SStreamExceptio n(which extends std::exception) resulting in a runtime dynamic error message. I guess this uses the delegate pattern. I am satisfied with these semantics and it should make my exception definitions look clean and elegant.

The Following is the underlying machinery to support the dynamic what() method.

#include <sstream>
#include <string>
#include <windows.h>
 
/* Uses std::string to maintain the string. string::c_str() is a (const char *). 
 * if std::stringstream::str()::c_str() is used the intermediary string object
 * vanishes at end of scope (return). Note that it derives from strinstream 
 */
class DynamicConstString
    : public std::stringstream
{
private : 
    std::string * _privateConstString;
public:
    DynamicConstString()
        : _privateConstString(NULL)
    {
        _privateConstString=new std::string();
    }
    ~DynamicConstString()
    {
        if(_privateConstString!=NULL)
            delete _privateConstString;
    }
 
    /* prior to a clear the string is constant */
    const char * getCString()
    {
        _privateConstString->assign((*this).str());
        return _privateConstString->c_str();
    }
 
    /* empty the string state in preparation of new data */
    void recycle()
    {
        _privateConstString->assign("");
        (*this).str(*_privateConstString);
    }
};
 
 
class SStreamException
    : public std::exception
{
    char * file;
    DWORD line;
    /* For some reason (cannot remember)  the following two objects need to be 
     * heap allocated for const correctness */
    DynamicConstString * __debugMsgString;
    DynamicConstString * __bodyString;
 
public:
    /* Following methods need to be defined by the Children */
    virtual const char * getType() const
    {
        return "Type Unspecified";
    }
    virtual void getBody(std::stringstream & _bodyString_in) const
    {
           _bodyString_in << "";
    }
 
    SStreamException(char * file_in, DWORD line_in)
        : file(file_in), line(line_in),__debugMsgString(NULL),__bodyString(NULL)
    {
        __debugMsgString=new DynamicConstString();
        __bodyString=new DynamicConstString();
    }
    ~SStreamException()
    {
        if(__debugMsgString!=NULL)
            delete __debugMsgString;
        if(__debugMsgString!=NULL)
            delete __bodyString;
    }
 
 
 
    const char * what() const throw()
    {
 
        __debugMsgString->recycle();
        __bodyString->recycle();
 
        std::stringstream & debugMsgString=*__debugMsgString;
        std::stringstream & bodyString=*__bodyString;
 
        debugMsgString << "Exception : " << getType() << std::endl;
        debugMsgString << "(" << file << ":" << line << ")" << std::endl;
 
        getBody(bodyString);
 
        /* if (bodyString.str()) is not used the pointer of (__bodystring) is used 
         * for some reason. weird reason */
        debugMsgString << (bodyString.str());
 
        return __debugMsgString->getCString();        
    }
};
 

To end I guess the core things I want to know are,

(1) Why the hell is what() marked as a const function ? is this braindead
or is there a justification for this.

(2) Have I circumvented the const correctness of std::exception: :what()

(3) is their a more elegant way to do this.

(4) are there more specialized libraries that do what I am trying to do for c++. (perhaps in boost ? Or Such).

(5) Could someone point me to some advanced articles on const correctness and the pitfalls of C++ object orientation.

(6) Is C++0x or the TR1 of boost attempting to make expressing such semantics in C++ better ? (perhaps the new garbage collector) And if so How ?

Looking forward to your feedback

Regards

Vain

[weaknessforcats]

The STL exception::what () is a const member function so you can use with const objects.

It returns a const char* so you can't alter the string pointed at since that may itself be a const string.

Personally, when I use this thing, my override a) dumps all my data to a log file, b) obtains the userid, machine name, IP address, system date an time, etc... and dumps all that to the log file.

Then I return "It bombed!".

exception::what () was never intended to be used just by looking at the returned char*.

Since you are an advanced C++ developer, you know that a cast of any kind means a) you are calling a relic C function, or b) your C++ design is screwed up.

That said, you never alter const. The only safe alteration of const is to const_cast a const object to a non_const object so you can call a non-const function with a const object. Going the other way, a const_cast is only safe when you know the non-const object was const to begin with. All other const casts are hacks and elicit undefined behavior by your compiler.

This is basic Stroustrup and it's in his book.

The one weakness of the STL is that is persists in using public virtual functions which are a big no-no since they merge the implementation (the virtual function) with the interface (the public methods). Scott Meyers has material on this or you could just look at the Template design pattern.

[vainstah]

const_cast had completely slipped my mind. If I had marked the objects I am using for string manipulation as const (I think) I would not have had to add an extra level of indirection to my code, I would have done a const_cast.

Your tip has directly addressed my confusion. Thank you.

I am still a bit miffed at how the const keyword is used in C++. I appreciate the need for it in the design of an API and as a tool to reduce complexity. I guess by specifying the virtual function as const the library writer can say "Hey MR. DeriveFromMyObj ect,, I don't want to be responsible for altering the state of your object, so I will ask Mr. Compiler to police you".

Now that I understand the problem and its solution I am wondering if perhaps in this scenario the prevention of misuse should better be left to the programmer ? It lowers the barrier to entry for C++ programming. In my opinion the real skill lies in understanding the low-level programming and not in the knowledge of a complex language.

[weaknessforcats]

In my opinion the real skill lies in understanding the low-level programming and not in the knowledge of a complex language.

True for C but not true for C++.

C++ precisely wants you to avoid that low-level stuff. That's why there is an STL that uses algorithms of only none, one or two arguments. More argments that that need intermediate binder objects. All of this to avoid constant recoding of low-level stuff.

With C++ you stay with creating derived objects that are manipulated using base class pointers. Derived methods not in the base class are executed by using a Visitor. Derived objects that are modified notify a Mediator who sends messages to the necessary Obervers.