Deleting an object if the constructor failed.

g4j31a5 · 09-15-2009, 01:46 AM

Hi guys, I want to ask you about how to delete an object if its constructor failed to initialize one of its members. I tried it like below but failed:

Code:

B* A:CreateB(std::string paramStr)
{
    B* pB= NULL;
    try
    {
         pB = new pB (paramStr);
    }
    catch (int result)
    {
         if (result == OK) // OK == 1
         {
                m_VectorB.push_back(pB);
         }
          else if (result == FAILED)
         {
                delete pB;
                pB = NULL;
         }
    }
    return pB;
}

B::B(std::string paramStr)
{
    int result = initMembers (paramStr); //returns OK / 1 if successful or FAILED / 0 if failed
    throw result ;
}

Now, FYI, I have never ever ever used exception in my entire life as a programmer. All my error handlings are either by return value or assertion. I know that it is not a good habit but I still don't have a good understanding about it. So, how can I solve this problem? Thanks in advance.

Sebastiani · 09-15-2009, 02:21 AM

First let's clarify what 'delete' means: to invoke the destructor and then release the memory (internally, usually done using free()) associated with the object. Furthermore, only the 'owner' of the object calls 'delete' on an object. If you're assigning the result of 'new' to a raw pointer (very bad idea) then that would be you. Otherwise, it's whatever container you're using to manage it with.

So then I suppose the question is "does a destructor get invoked on a partially constructed object?" (eg: when an exception is thrown, but not caught, during the constructor). The answer is 'no' (it will, however, be called on whatever class members were fully constructed up to that point).

As far as throwing integers as return values, IMO, the is a very bad design. There are a lot of differing opinions on the matter, but the general consensus is that exceptions should only be thrown from an object in the most extreme situations (eg: 'fatal' errors). On the other hand, exceptions thrown and caught from within the same object is often a useful technique for overcoming complicated control-flow situations, but that's a different matter entirely.

anon · 09-15-2009, 02:45 AM

new does two things: a) allocate memory, b) call constructor. delete does the opposite: a) call destructor, b) deallocate memory.

Now if the constructor throws an error, new deallocates the memory and rethrows the exception. Also, when the constructor throws, the object never comes to existence (members initialized so far are destroyed) and therefore it would be an error to invoke the destructor on the zombie.

So your attempt to signal success by throwing an exception from a constructor couldn't possibly work.

Correct way:

Code:

B* A::CreateB(std::string paramStr)
{
   //no special error handling needed here
   //some caller handles allocation/construction failures
    B* pB = new pB (paramStr);

    //if the previous line didn't throw (= if we get this far in the first place), everything's OK
    m_VectorB.push_back(pB);
         
    return pB;
}

B::B(std::string paramStr)
{
    int result = initMembers (paramStr); //returns OK / 1 if successful or FAILED / 0 if failed
    if (!result) throw some_exception("something is wrong"); //only throw in case of failure
}

**CornedBee** · 09-15-2009, 03:23 AM

Of course, even better would be to have each member initializer in turn use exceptions to signal errors, because the entire point of exceptions is that they propagate upwards automatically.

**laserlight** · 09-15-2009, 04:16 AM

I suggest that you read GotW #66: Constructor Failures.

g4j31a5 · 09-15-2009, 10:13 PM

Thanks for the reply guys

@Sebastiani: Well, I know that the 'new' method mallocs and then calls the constructor and 'delete' calls the destructor and then free the memory. What I don't know is how exception works in general. And I thought that the object will be fully created even if I throw an exception in the constructor. I guess I'm wrong.

About passing int as an exception, yeah, I know that it's not a good idea. But it is sufficient as of now.

BTW, as for assigning 'new' to a raw pointer, I've seen lots of open source libraries do that also. So i thought, why can't I?

@anon: OIC, I thought we can throw anything at anytime. My mistake then. BTW, your code didn;t work. I tried this one though and it worked:

Code:

B* A:CreateB(std::string paramStr)
{
    B* pB= NULL;
    try
    {
         pB = new pB (paramStr);
    }
    catch (int result)
    {
          pB = NULL;
    }

    m_VectorB.push_back(pB);
    return pB;
}

B::B(std::string paramStr)
{
    int result = initMembers (paramStr); //returns OK / 1 if successful or FAILED / 0 if failed
    if (result == FAILED)
                   throw result ;
}

@CornedBee: Well I would if there's no time constraint. Heck, I will rewrite the entire code with exceptions if there's time. But for now, it's okay to do this quick hack. :P

@laserlight: Thanks. Another source of information is always good.

Sebastiani · 09-16-2009, 12:24 AM

Quote:

BTW, as for assigning 'new' to a raw pointer, I've seen lots of open source libraries do that also. So i thought, why can't I?

Yes, unfortunately it's fairly common, actually. There are numerous good articles on the subject (ie: RAII), but briefly, consider this bit of code:

Code:

struct fatal
{    };

struct object
{
    object( bool chaos )
    {
        if( chaos )
            throw fatal( );
        cout << "object( )" << endl;    
    }
    
    virtual ~object( void )
    {
        cout << "~object( )" << endl;    
    }    
};

void test( void )
{
    object*
        ptr = new object( false );
    object
        obj( true );
}

int main( void )
try
{
    test( );
}
catch( ... )
{    }

Output:

Quote:

object( )

Here, 'ptr' is not 'protected' by a destructor, so when/if an exception is thrown, it never gets cleaned up. You might be tempted to do something like this:

Code:

void test( void )
{
    object*
        ptr;
    try
    {
        ptr = new object( true );
        object
            obj( true );
    }
    catch( ... )
    {
        delete ptr; // whoops!
    }
}

But that isn't correct either. In this case, the exception was thrown while allocating 'ptr', so an invalid delete is applied!

You might think you could simply call delete if the exception isn't an std::bad_alloc, but unfortunately, that won't work since it could have originated from anywhere between the try block.

The solution, of course, is to follow the RAII strategy:

Code:

void test( void )
{
    std::auto_ptr< object >
        ptr( new object( false ) );
    object
        obj( true );
}

Output:

Quote:

object( )
~object( )

Perfect!

**CornedBee** · 09-16-2009, 01:15 AM

Doing exceptions without strictly following RAII principles is just setting yourself up for lots and lots of headaches, and bugs in code paths that are very rarely tested.

abachler · 09-16-2009, 01:41 AM

Quote:

Originally Posted by g4j31a5

BTW, as for assigning 'new' to a raw pointer, I've seen lots of open source libraries do that also. So i thought, why can't I?

I commonly assign new to LPVOID when I am abstracting a class to hide internal details when distributing a closed source middelware library. This way I can have a header with only the public methods and data showing, enforcing privatization and at the same time protecting trade secrets.

e.g.

Code:

class Public_Class {
   LPVOID pObject;

   // public functions and data go here

then in the actual constructor

Code:

Public_Class::Public_Class(){

   this->pObject = (LPVOID) new ActualClass();

   return;
   }

Since my public class functions will have access tot he ActualClass header they can manipulate the object by recasting pObject to (ActualClass*), but the end user only gets the compiled library and the Public_Class header, so they do not have access to the ActualClass member functions or variables and can only access it through the methods I allow.

**CornedBee** · 09-16-2009, 03:25 AM

But why not do this?

Code:

class Public_Class {
  class Impl;
  boost::scoped_ptr<Impl> m_impl; // or equivalent to scoped_ptr

public:
  Public_Class();
  ~Public_Class();
};

// implementation:
class Public_Class::Impl
{
  // ...
};

Public_Class::Public_Class()
  : m_impl(new Impl)
{}
Public_Class::~Public_Class()
{} // Empty. It's only out-of-line to force an instantiation location for scoped_ptr's destructor.

No casting, no chance of exception unsafety. You have to implement copying if you want it, of course, but you have to do that anyway.

IceDane · 09-16-2009, 06:19 AM

Not my intention to hijack the topic - but the reason you shouldn't be using new directly with raw pointers with custom objects is more or less because it never goes out of scope, due to the simple fact that it's not allocated on the stack? And using std::auto_ptr solves this for us because when it goes out of scope, it destroys the objects it is encapsulating?

Very informative post - still learning how to write proper code in C++.

**CornedBee** · 09-16-2009, 06:29 AM

Quote:

but the reason you shouldn't be using new directly with raw pointers with custom objects is more or less because it never goes out of scope, due to the simple fact that it's not allocated on the stack?

More generally, you shouldn't do it because you have to explicitly control (and document) the lifetime and ownership of the object, whereas smart pointers automate, enforce and document a specific ownership and lifetime model. For example, scoped_ptr enforces single, local ownership with scoped lifetime. If you see a scoped_ptr, you know that this is the case. If you see a raw pointer, you always have to wonder.

IceDane · 09-16-2009, 06:46 AM

Quote:

Originally Posted by CornedBee

More generally, you shouldn't do it because you have to explicitly control (and document) the lifetime and ownership of the object, whereas smart pointers automate, enforce and document a specific ownership and lifetime model. For example, scoped_ptr enforces single, local ownership with scoped lifetime. If you see a scoped_ptr, you know that this is the case. If you see a raw pointer, you always have to wonder.

I see. Thanks =)

I was actually wondering how I should go about solving a problem, and by surfing this forum, not looking for the solution at all, I stumbled upon it, heh.

g4j31a5 · 09-17-2009, 08:34 AM

@Sebastiani & CornedBee: RAII? what's that? sorry that's still new to my ear. I swear, the profs have never mentioned that word when I was in college. -_-a

@abachler: LPVOID is the same as void*, right? Although it's doable, it's too much of a hassle IMHO. I rarely use void* so that the code can be read better. :P

You know, I've also never used auto_ptr. It's not portable IIRC. Maybe I'll try it in the future. As for passing pointers out of scope, I usually does that and control them strictly by myself. So I have to make sure if the object is still alive or not before doing anything to it on different objects. I usually code what came up first in my head. I confess, I suck at designing my codes. :P

**laserlight** · 09-17-2009, 08:43 AM

Quote:

Originally Posted by g4j31a5

You know, I've also never used auto_ptr. It's not portable IIRC.

It is part of the C++ standard library.

09-15-2009, 01:46 AM	#1
g4j31a5 In the Land of Diddly-Doo Join Date: Jul 2006 Posts: 381	Deleting an object if the constructor failed. Hi guys, I want to ask you about how to delete an object if its constructor failed to initialize one of its members. I tried it like below but failed: Code: B* A:CreateB(std::string paramStr) { B* pB= NULL; try { pB = new pB (paramStr); } catch (int result) { if (result == OK) // OK == 1 { m_VectorB.push_back(pB); } else if (result == FAILED) { delete pB; pB = NULL; } } return pB; } B::B(std::string paramStr) { int result = initMembers (paramStr); //returns OK / 1 if successful or FAILED / 0 if failed throw result ; } Now, FYI, I have never ever ever used exception in my entire life as a programmer. All my error handlings are either by return value or assertion. I know that it is not a good habit but I still don't have a good understanding about it. So, how can I solve this problem? Thanks in advance. __________________ ERROR: Brain not found. Please insert a new brain! “Do nothing which is of no use.” - Miyamoto Musashi. Last edited by g4j31a5; 09-15-2009 at 01:54 AM.
g4j31a5 is offline

09-15-2009, 02:21 AM	#2
Sebastiani Guest Join Date: Aug 2001 Posts: 5,034	First let's clarify what 'delete' means: to invoke the destructor and then release the memory (internally, usually done using free()) associated with the object. Furthermore, only the 'owner' of the object calls 'delete' on an object. If you're assigning the result of 'new' to a raw pointer (very bad idea) then that would be you. Otherwise, it's whatever container you're using to manage it with. So then I suppose the question is "does a destructor get invoked on a partially constructed object?" (eg: when an exception is thrown, but not caught, during the constructor). The answer is 'no' (it will, however, be called on whatever class members were fully constructed up to that point). As far as throwing integers as return values, IMO, the is a very bad design. There are a lot of differing opinions on the matter, but the general consensus is that exceptions should only be thrown from an object in the most extreme situations (eg: 'fatal' errors). On the other hand, exceptions thrown and caught from within the same object is often a useful technique for overcoming complicated control-flow situations, but that's a different matter entirely.
Sebastiani is offline

09-15-2009, 03:23 AM	#4
CornedBee Cat without Hat Join Date: Apr 2003 Posts: 8,492	Of course, even better would be to have each member initializer in turn use exceptions to signal errors, because the entire point of exceptions is that they propagate upwards automatically. __________________ All the buzzt! CornedBee "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code." - Flon's Law
CornedBee is offline

09-15-2009, 04:16 AM	#5
laserlight C++ Witch Join Date: Oct 2003 Location: Singapore Posts: 11,320	I suggest that you read GotW #66: Constructor Failures. __________________ C + C++ Compiler: MinGW port of GCC Build + Version Control System: SCons + Bazaar Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
laserlight is offline

09-15-2009, 10:13 PM	#6
g4j31a5 In the Land of Diddly-Doo Join Date: Jul 2006 Posts: 381	Thanks for the reply guys @Sebastiani: Well, I know that the 'new' method mallocs and then calls the constructor and 'delete' calls the destructor and then free the memory. What I don't know is how exception works in general. And I thought that the object will be fully created even if I throw an exception in the constructor. I guess I'm wrong. About passing int as an exception, yeah, I know that it's not a good idea. But it is sufficient as of now. BTW, as for assigning 'new' to a raw pointer, I've seen lots of open source libraries do that also. So i thought, why can't I? @anon: OIC, I thought we can throw anything at anytime. My mistake then. BTW, your code didn;t work. I tried this one though and it worked: Code: B* A:CreateB(std::string paramStr) { B* pB= NULL; try { pB = new pB (paramStr); } catch (int result) { pB = NULL; } m_VectorB.push_back(pB); return pB; } B::B(std::string paramStr) { int result = initMembers (paramStr); //returns OK / 1 if successful or FAILED / 0 if failed if (result == FAILED) throw result ; } @CornedBee: Well I would if there's no time constraint. Heck, I will rewrite the entire code with exceptions if there's time. But for now, it's okay to do this quick hack. :P @laserlight: Thanks. Another source of information is always good. __________________ ERROR: Brain not found. Please insert a new brain! “Do nothing which is of no use.” - Miyamoto Musashi.
g4j31a5 is offline

09-16-2009, 01:15 AM	#8
CornedBee Cat without Hat Join Date: Apr 2003 Posts: 8,492	Doing exceptions without strictly following RAII principles is just setting yourself up for lots and lots of headaches, and bugs in code paths that are very rarely tested. __________________ All the buzzt! CornedBee "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code." - Flon's Law
CornedBee is offline

09-16-2009, 03:25 AM	#10
CornedBee Cat without Hat Join Date: Apr 2003 Posts: 8,492	But why not do this? Code: class Public_Class { class Impl; boost::scoped_ptr<Impl> m_impl; // or equivalent to scoped_ptr public: Public_Class(); ~Public_Class(); }; // implementation: class Public_Class::Impl { // ... }; Public_Class::Public_Class() : m_impl(new Impl) {} Public_Class::~Public_Class() {} // Empty. It's only out-of-line to force an instantiation location for scoped_ptr's destructor. No casting, no chance of exception unsafety. You have to implement copying if you want it, of course, but you have to do that anyway. __________________ All the buzzt! CornedBee "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code." - Flon's Law
CornedBee is offline

09-16-2009, 06:19 AM	#11
IceDane Ex scientia vera Join Date: Sep 2007 Posts: 464	Not my intention to hijack the topic - but the reason you shouldn't be using new directly with raw pointers with custom objects is more or less because it never goes out of scope, due to the simple fact that it's not allocated on the stack? And using std::auto_ptr solves this for us because when it goes out of scope, it destroys the objects it is encapsulating? Very informative post - still learning how to write proper code in C++. __________________ "What's up, Doc?" "'Up' is a relative concept. It has no intrinsic value."
IceDane is offline

09-17-2009, 08:34 AM	#14
g4j31a5 In the Land of Diddly-Doo Join Date: Jul 2006 Posts: 381	@Sebastiani & CornedBee: RAII? what's that? sorry that's still new to my ear. I swear, the profs have never mentioned that word when I was in college. -_-a @abachler: LPVOID is the same as void, right? Although it's doable, it's too much of a hassle IMHO. I rarely use void so that the code can be read better. :P You know, I've also never used auto_ptr. It's not portable IIRC. Maybe I'll try it in the future. As for passing pointers out of scope, I usually does that and control them strictly by myself. So I have to make sure if the object is still alive or not before doing anything to it on different objects. I usually code what came up first in my head. I confess, I suck at designing my codes. :P __________________ ERROR: Brain not found. Please insert a new brain! “Do nothing which is of no use.” - Miyamoto Musashi.
g4j31a5 is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Deleting object after list removal (C++ visual studio)	RancidWannaRiot	Windows Programming	2	10-20-2005 06:06 PM
Question on l-values.	Hulag	C++ Programming	6	10-13-2005 04:33 PM
A question about constructors...	Wolve	C++ Programming	9	05-04-2005 04:24 PM
deleting dynamic object problem	eth0	C++ Programming	17	05-19-2004 01:17 PM
Array of Pointers + Deleting An Object = Problems	Nereus	C++ Programming	3	03-04-2004 12:16 PM