exceptions in constructor

[vaclavpich@atlas.cz]

Hi
I've a question about constructors and exceptions.
//*************** *************** *************** ***************
class CObject
{
public:
// ctor
CObject();
// dtor
~ CObject();

// ... methods
};

CObject::CObjec t()
{
// 1) if ( FAILED( LoadLibrary(... ) )) throw exception1;

// 2) if ( FAILED(CoInitia lize( 0 )) throw exception2;

// 3) if ( FAILED( CoCreateInstanc e(....))) throw exception3;
}

CObject::~CObje ct()
{
// 1) release COM interface

// 2) CoUninitialize( );

// 2) FreeLibrary
}

int main(int avgv, char** argc)
{
try{
CObject* ptrObj = new CObject;
}
catch(exception & exc)
{...}
return 0;
}
//*************** *************** *************** *************** ****
When an error occurs in constructor there is only one way how to say
that samething wrong happen.You can throw an exception but is then a
pointer to CObject valid ?
So can you call detructor ~CObject() to release resources. I mean
this : delete ptrObj;

Is really constructor good place to attach resources (load library or
to get COM interface) ?
I'm not sure.

I've seen another way. Constructor and destructor are very simple
methods.
All resources are attached in method Initialize and released in
Uninitialize.
These methods can return error codes.

Can anybody explain it to me.
Thanks.

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

Re: exceptions in constructor

On 2008-10-18 18:29, vaclavpich@atla s.cz wrote:

Hi
I've a question about constructors and exceptions.
//*************** *************** *************** ***************
class CObject
{
public:
// ctor
CObject();
// dtor
~ CObject();
>
// ... methods
};
>
CObject::CObjec t()
{
// 1) if ( FAILED( LoadLibrary(... ) )) throw exception1;
>
// 2) if ( FAILED(CoInitia lize( 0 )) throw exception2;
>
// 3) if ( FAILED( CoCreateInstanc e(....))) throw exception3;
}
>
CObject::~CObje ct()
{
// 1) release COM interface
>
// 2) CoUninitialize( );
>
// 2) FreeLibrary
}
>
int main(int avgv, char** argc)
{
try{
CObject* ptrObj = new CObject;
}
catch(exception & exc)
{...}
return 0;
}
//*************** *************** *************** *************** ****
When an error occurs in constructor there is only one way how to say
that samething wrong happen.You can throw an exception but is then a
pointer to CObject valid ?
So can you call detructor ~CObject() to release resources. I mean
this : delete ptrObj;

No, there will be no object, so you can not get a pointer to it. On the
other hand you do not have to worry about destroying it either, it is
all taken care of by new.

Is really constructor good place to attach resources (load library or
to get COM interface) ?
I'm not sure.

The C++ programming RAII idiom relies on the constructor allocating all
the resources needed. You should, however, take care to ensure that you
do not leek resources if the constructor throws by doing some exception
handling inside the constructor too:

CObject::CObjec t()
{
// LoadLibrary(... ), if this throws no harm done

try {
// Allocate(...), if this throws we need to clean up
}
catch(...) {
// Clean up, free allocated memory etc.
throw; // Re-throw the exception
}

try {
// Initialise(...) , will require clean up too
}
catch(...) {
// Clean up from initialisation
// Free memory etc
throw; // Re-throw the exception
}
}

I've seen another way. Constructor and destructor are very simple
methods.
All resources are attached in method Initialize and released in
Uninitialize.
These methods can return error codes.

This is called two stage initialisation, and many consider it a bad thing.

--
Erik Wikström

[asm23]

Re: exceptions in constructor

I suggest you can read the <<Thinking C++>volume TWO. The First
Chapter has a detail explanation covering your problem including the
exceptions in constructors and "RAII idiom". The book can be downloaded
from

http://mindview.net/Books/TICPP/ThinkingInCPP2e.html

[Andre Kostur]

Re: exceptions in constructor

vaclavpich@atla s.cz wrote in news:a86624e5-ceef-4c5c-a369-21f67fb935e4
@d31g2000hsg.go oglegroups.com:

Hi
I've a question about constructors and exceptions.
//*************** *************** *************** ***************
class CObject
{
public:
// ctor
CObject();
// dtor
~ CObject();
>
// ... methods
};
>
CObject::CObjec t()
{
// 1) if ( FAILED( LoadLibrary(... ) )) throw exception1;
>
// 2) if ( FAILED(CoInitia lize( 0 )) throw exception2;
>
// 3) if ( FAILED( CoCreateInstanc e(....))) throw exception3;
}
>
CObject::~CObje ct()
{
// 1) release COM interface
>
// 2) CoUninitialize( );
>
// 2) FreeLibrary
}
>
int main(int avgv, char** argc)
{
try{
CObject* ptrObj = new CObject;
}
catch(exception & exc)
{...}
return 0;
}
//*************** *************** *************** *************** ****
When an error occurs in constructor there is only one way how to say
that samething wrong happen.You can throw an exception but is then a
pointer to CObject valid ?

ptrObj would not have been assigned anything, and in your code would
immediately go out of scope, and thus can not be used anyway.
(Different question: Why are you attempting to new the object anway?
Why not simply declare it as a local variable and then you don't have to
worry about the memory?)

So can you call detructor ~CObject() to release resources. I mean
this : delete ptrObj;

How? There's no way to use ptrObj in the code shown. There's nothing
for you to delete. It won't be used in the try block since the
exception will cause the execution flow to immediately jump to the catch
block, and within the catch block ptrObj is already out of scope and
thus cannot be used.

Is really constructor good place to attach resources (load library or
to get COM interface) ?
I'm not sure.

Sure, but you'd probably want to wrap those in their own RAII classes so
that in the event of them going out of scope, they will dispose of
themselves properly.

I've seen another way. Constructor and destructor are very simple
methods.
All resources are attached in method Initialize and released in
Uninitialize.
These methods can return error codes.

That would be another way. Depends on how you want to use your class.
With the exception-based method you know that your object is always in a
sane and usable state. With the initializtion-based method, your object
has 3 states to worry about: Uninitialized, Initialized, and
Uninitialized but was previously initialized (This might be the same
state as simply Uninitialized).