Cyclic dependency in throw declaration

[sgurukrupagmailcom]

Hi,

I am unable to get the following to compile

struct m
{
        void n ( ) throw ( m ) ;
} ;
 
int main ( )
{
}

I am using g++ ( GNU version of c++ compiler ) to compile. It throws the following error:

m.cpp:3: error: invalid use of incomplete type 'struct m'
m.cpp:2: error: forward declaration of 'struct m'
 

[weaknessforcats]

You cannot throw an m object from inside the struct m declaration. At this point the compiler does not know what an m object is exactly. Like, is there a default constructor, or maybe more data members, etc..

As a result it doesn't know what code to generate. That is, not until it reaches the end of the struct declaration.

You will need to throw an m*.

Since the compiler has seen "struct m", that is enough information to allow an m*.

[sgurukrupagmailcom]

Hi weaknessforcats,

Thanks for your kind reply. I knew that there should be a simple workaround for this design problem. The solution that you suggested is very simple, I just throw a pointer to the struct instead of the actual object.

Warm Regards,
Gaura

[sgurukrupagmailcom]

Hi,

Sorry folks. I hadn't actually tried compiling the above code with the change included. The change that we thought would work was: throwing a pointer to 'struct m' rather than throwing an instance of 'struct m' itself. To be more clear what I am trying to say is that the code below

struct m
{
    void n ( ) throw ( m * ) ;
    int val ;
} ;
 
int main ( )
{
return 0 ;
}
 

should compile when using g++. BUT it doesn't! Surprising! Trying to compile the code above gives the same compilation errors that I quoted earlier in this thread. Desperate to make the above piece of code compile, I modified the 3rd line to

void n ( ) throw ( m * * )

and miraculously it compiled! What could be the reason that g++ doesn't allow throwing a pointer to 'struct m' but allows a pointer to a pointer to 'struct m' ? Could any one enlighten me ?

Warm Regards,
Gaura

[weaknessforcats]

I have no idea why g++ is doing this. m** or m* is still just a pointer.

I use Visual Studio.NET but this tool does not yet support exception specifications so I can't compile your code exactly. VS currently just ignores the exception specification.

[RRick]

Well, you learn something every day. It looks like a class can not throw itself from a member function. g++ keeps complaining about a using an incomplete class in the throw declaration.

Why this is so is beyond me. If you are really interested in an answer I would go to the source and talk to the C++ news group (comp.lang.c++). They have been my source for weird questions like this. If you do find out what is going on, be sure to let us know.


WARNING WILL ROBINSON: A word of caution is needed here. An exception is a resource and in C++ that means you have to deal with it. If you throw a pointer to something, that means you have new/malloc the object before you throw it and also clean it up sometime later.

The best way to deal with exceptions is to let the C++ compiler deal automatically with the resources itself. This means you throw a real object and catch references to that object. That way you can inspect and re-throw an exception any number of times.

[sgurukrupagmailcom]

Hi,

Well, the reason I am trying to solve this weird problem is because of the following design that I want to implement.

I have an 'exception' class that no other function must be able to throw except a select group of functions. I want the compiler to prohibit people who use my code the capability of throwing instances of my exception class. However they will still be able catch objects of the exception class. Why do I want to do this ? This brings clarity to the working of the code - the source of all instances of my exception class is only one - my code. I could have easily acheived this in Java by making the constructor of my exception class package-private ( which I acheive by not specifying any access modifier for the constructor ) . I would then put the exception class inside the package where my code will be making new instances of the exception class. But C++ lacks this kind of access modifier. Now how should I design my exception class to achieve this in C++ ?

I resorted to making the constructor of my exception class as private and making all the functions of my code which will be allowed to throw instances of this exception class, as 'friend's of the class. A representative piece of code of this design is given here:

struct m
{
        private:
                m ( )
                { }
 
        friend void myFunc ( ) throw ( m ) ;
} ;
 
int main ( )
{
        return 0 ;
}

But unfortunately as I narrate at the beginning of this thread, the g++ compiler doesn't allow me to do this. Does anyone have a better idea of going about implementing the design that I have just talked about.

Warm Regards,
Gaura

[unauthorized]

Did you try exporting your function outside the class body?

class myException // you should really ": public std::exception" all custom exceptions
{
private:
     myException MakeObj();
 
     friend classA;
     friend classB;
     etc.....
}
 
// This in a separate compile module (e.g. another cpp file).
// If you do this in the header, including it twice will cause linker errors.
myException myException::MakeObj()
{
     return myException();
}

This method allows you to specify which classes can instance the exception.

Now this code has a lot of overhead, but I expect your compiler would be reasonable enough not to instance the same object, copy it, and then destroy the first instance after optimization.

[RRick]

The above posting is one solution, but has the problem of modifying the exception class for every new accessing object.

You can minimize those additions by making an application base class a friend of the exception, but now you have to hide the application base class from the users and only the methods in the application base class would be able to throw the exceptions.


The most useful exception class structure I have found, is creating an application exception base class. All of the application's exceptions are derived from that base class. To catch any application exception you just catch the base class.

To limit access for this system the application object's would have to be friends to both the base and derived exception classes. Ugh.


I have found that when you can try to program around a language's limitation, the solution is not usually optimal or maintainable or very pretty. In this case, why is the limiting the creation of the exception so important?

I have found that most applications use their own exceptions. The general rule is that you use yours and I use mine and everyone is happy.

[sgurukrupagmailcom]

Hi RRick,

You got to the root of my problem. I am being too obsessive about not allowing others to create instances of my exception class. It's not going to hurt anyone, if they do. However on the positive side my quest did spark off an instructive discussion at the comp.lang.c++ group. click here to see.
This thread does answer the questions raised here. Rick, I have got a few more things to say about handling exceptions in C++ in my next post. ( Lot of work pressure at office ! )

Warm Regards,
Gaura

[weaknessforcats]

You might read this: http://bytes.com/topic/c/insights/65...erns-singleton

[sgurukrupagmailcom]

Hi,

The singleton design pattern was an interesting article on controlling the number of instances that a user of the class can create.

The warning that RRick gave near the beginning of the thread about throwing exception as pointer to an object is something that we need to heed. It's better to drop the idea of throwing pointer to objects, otherwise it would lead to increased complexity in maintaining the code.

Warm Regards,
Gaura

[RRick]

You're getting the right idea about exceptions; there are good and bad ways to deal with them. These issues can be as bad as crash and burn (i.e. throwing an exception within a destructor) or as pernicious and difficult to find as a memory leak.

FYI: The following link has some of the caveats for exception creation and handling. http://www.parashift.com/c++-faq-lit....html#faq-17.3

Cheers.