constrctor

I have a constructor that calls a function that return a value
if the function fails what can I do can I stop constructing the object?
How do I notify the client who created the object that there was a failure?

I mean
Client side:
CMyClass myClass;

and myClass constructor do that:

MyClass::MyClass
(
Init1();
Init2();
}

what if Init1() or Init2() fails??

If I am not wrong, I think you can throw an exception in your constructor.

How will the client creating the class object
will know about the failure?

By catching the exception

Throw an exception. The catcher can find out what happened. If you use auto_ptr, it will also free the memory.

can you please show me how what do i do with this try catch at the client side?

I mean my client side do:

MyClass myClass; //how do I know here if exception was thrown??


and MyClass constructor looks like that

try
{
if(Init1() != OK)
//throw exception here?, what kind
if(Init2() != OK)
//throw exception here?, what kind
}
catch() //catch what exception
{

}

One idea:

Code:

---

CYourClass::CYourClass
{
    if( !Init() )
    {
        CWhateverExceptionYouWant TheEx;
        // Set up TheEx
        throw TheEx;
    }
}

---

Code:

---

try
{
    CYourClass Yadda;
    UseYadda( Yadda );
}
catch( CWhateverExceptionYouWant& rTheEx )
{
    // Use rTheEx...
}

---

Code:

---

void UseYadda( CYourClass& rYadda )
{
    // ...
}

---

Personally, I avoid throwing exceptions from constructors whenever possible (usually always). As you can see, it is kind of a pain. If you do decide that your constructor should throw, you should make it very well known that it can throw an exception.

How many classes do you know of, where the constructor throws an exception?

Quote:

---

Originally posted by vicodin451
One idea:

Code:

---

CYourClass::CYourClass
{
    if( !Init() )
    {
        CWhateverExceptionYouWant TheEx;
        // Set up TheEx
        throw TheEx;
    }
}

---

I don't understand this part is this the client?

Code:

---

try
{
    CYourClass Yadda;
    UseYadda( Yadda );
}
catch( CWhateverExceptionYouWant& rTheEx )
{
    // Use rTheEx...
}

---

Code:

---

void UseYadda( CYourClass& rYadda )
{
    // ...
}

---

Personally, I avoid throwing exceptions from constructors whenever possible (usually always). As you can see, it is kind of a pain. If you do decide that your constructor should throw, you should make it very well known that it can throw an exception.

How many classes do you know of, where the constructor throws an exception?

---

----------------------------------------------------------------

I haven't seen, but can you tell me what else can I do if the function I call in my constructor fails, how can I inform my client not to call functions of that class?

Quote:

---

Originally posted by avi123
I haven't seen, but can you tell me what else can I do if the function I call in my constructor fails, how can I inform my client not to call functions of that class?

---

Well, what I prefer to do is to require a function such as Initialize() to be called prior to using the object. Initialize can return a BOOL or bool to indicate success/failure, or a DWORD error code, or throw an exception, etc. If Initialize fails, further operations on the object should not be performed.

Code:

---

CYourClass Yadda;
if( Yadda.Initialize() )
{
    UseYadda( Yadda );
}
else
{
    // Handle failure to initialize...
}

---

or

Code:

---

CYourClass Yadda;
try
{
    Yadda.Initialize();
    UseYadda( Yadda );
}
catch( CWhateverExceptionYouWant& rTheEx )
{
    // Handle exception...
}

---

thanks

that's what I did

Quote:

---

Well, what I prefer to do is to require a function such as Initialize() to be called prior to using the object. Initialize can return a BOOL or bool to indicate success/failure, or a DWORD error code, or throw an exception, etc. If Initialize fails, further operations on the object should not be performed.

---

My two cents: I used to do this, but now I generally don't like to do this, because it breaks the RAII idiom that I've grown so fond of. Not only that, but it's almost always unneccesary.

Secondly, since the user is going to have to be aware of how to use the class _anyway_ because you're forcing them to call Initialize() after they've constructed the object, there's no less work involved in requiring them to read the class/documentation to find out that the constructor throws one or more exceptions.

In my experience, making the users of the class call an arbitrary function or functions before using the class makes it more likely they'll use it incorrectly.

Regards,
Bassman

For those that are interested in a deeper discussion of constructors that throw exceptions (and exceptions in general), Robert Schmidt's "Deep C++", "Handling Exceptions" series of articles discusses throwing from a constructor (and much, much more). Particularly, parts 16 and 14.
Part 16
http://msdn.microsoft.com/library/de...ep02172000.asp

Part 14
http://msdn.microsoft.com/library/de...ep01202000.asp

Like anything else, the use of exceptions is fraught with debate and it's closer to a religious argument than it is to an objective cost-benefit analysis.

In this article specifically, the arguments the author uses are mostly semantic, such as immediately criticizing the 'Spirit of C++' and then moving on later to argue that an initialization function is better because objects can then return the status, "broken but functional."

How can an object be 'broken' and still functional? There's only two states an object can be in - functional, or not-functional. (I define functional as to mean the methods of the class will satisfy their pre/post conditions.)

If it's 'half-working', then that constitutes an error in the design of the object - a single object achieving multiple purposes that should probably have been two objects to begin with, one that is functional, one that is not.

Also, in my book, throwing an exception from the constructor doesn't say, "This object is broken beyond repair," it says, "This object is not usable in the way you've told me to use it either through the specified parameters or due to some other external factors." Since the author never explicitly defines what 'broken' means, he might even be saying about the same thing.

Regards,
Bassman

(All articles cites are from part 16)