Exceptions & Constructors

[jalqadir]

The constructor in MyClass instantiates many objects pointers through
'new', I would like to implement a way to make sure that the object
has been allocated in memory by catch(ing) the bad_alloc exception
error, but this means that I have to throw this error back from
MyClass constructor, how can I avoid this?

Thanks folks!

[tragomaskhalos]

On 30 Jul, 19:50, "Xavier Serrand" <xxxxxx.xxxx... @xxx.frwrote:

template <typename Tstatic Pile<T* createPile(int sz)
{
Pile<T* pp;
try
{
pp = new Pile<T>(sz);
return pp;
}
catch (std::bad_alloc &)
{
try
{
// clearing what can be cleared ...
// ...
// deleting the instance : the destructor has to be sure
// (may be hard to do...)
pp->~Pile<T>();
}
catch (std::exception & e)
{
// nothing to do
}
return NULL;
}
}

This is wrong isn't it? If bad_alloc is thrown then
the object won't have been constructed, so you don't
want to be calling the destructor on 'pp' - UB and
all that (not to mention the fact that pp is
uninitialised in this case anyway). In any case,
using new(nothrow) saves you having to mess about
with bad_alloc in the first place.

But as Alf has pointed out it's all largely academic,
if your program reaches this point you're probably
scuppered anyway, which reinforces my earlier
suggestion of keeping it simple and just letting the
exception propagate out of the ctor.

[BobR]

Erik Wikström wrote in message...

On 2007-07-30 13:15, ja******@gmail. com wrote:

The constructor in MyClass instantiates many objects pointers through
'new', I would like to implement a way to make sure that the object
has been allocated in memory by catch(ing) the bad_alloc exception
error, but this means that I have to throw this error back from
MyClass constructor, how can I avoid this?

Sure, add a flag to the class that tells if the object was constructed
correctly:

class Foo {
int* ptrarr[16];
public:
bool correct;
Foo() correct(true) {
try {
for (size_t i = 0; i < 16; ++i) ptrarr[i] = new int();
} catch(bad_alloc &){ correct = false; }
}
};

int main() {
Foo f;
if (f.correct == false) {
// Opps, failed to allocate
}
}

Re-worked for 'function-level try block' (just for an idea(OP)):

#include <stdexcept // #include <exception>
#include <new // bad_alloc

class Foo{
int *ptrarr[16];
public:
bool correct;

Foo() try : correct( true ) {

// yup, I found yer lost colon. <G>
// ( It was hangin' with a bad crowd at the Bar(). )

for (size_t i = 0; i < 16; ++i) ptrarr[i] = new int();
} catch( std::bad_alloc& ){
correct = false;

// delete what you new.
// throw;

} // catch
}; // class Foo

// or, the extreme: (not borland6)
#include <iostream // #include <ostream>
#include <stdexcept>
#include <new // bad_alloc

int main() try {
Foo f; // un-comment "throw;" in Foo's "catch()"
// throw "failure in main()"; // to test
} // main() end
catch( char const *msg) {
std::cout << msg << std::endl;
return 1;
}
catch( std::bad_alloc& ){
std::cout <<" Opps, failed to allocate!"<<std ::endl;
// throw;
return 1;
} // catch
catch( ... ){
std::cout <<" Unknown failure!"<<std: :endl;
return 1;
} // catch
Erik, I started to toss out this post[1], but, seeing other posts, it may
help somebody.

[1] - I only wanted to inform you I found your lost colon. :-}
Was that an "colon-oscopy"(sp?)?
[ corrections, comments welcome. ]
--
Bob R
POVrookie

[Xavier Serrand]

"tragomaskhalos " <da************ *@logicacmg.com a écrit dans le message de
news:11******** **************@ q75g2000hsh.goo glegroups.com.. .

On 30 Jul, 19:50, "Xavier Serrand" <xxxxxx.xxxx... @xxx.frwrote:

template <typename Tstatic Pile<T* createPile(int sz)
{
Pile<T* pp;
try
{
pp = new Pile<T>(sz);
return pp;
}
catch (std::bad_alloc &)
{
try
{
// clearing what can be cleared ...
// ...
// deleting the instance : the destructor has to be sure
// (may be hard to do...)
pp->~Pile<T>();
}
catch (std::exception & e)
{
// nothing to do
}
return NULL;
}
}

This is wrong isn't it? If bad_alloc is thrown then
the object won't have been constructed, so you don't
want to be calling the destructor on 'pp' - UB and
all that (not to mention the fact that pp is
uninitialised in this case anyway). In any case,
using new(nothrow) saves you having to mess about
with bad_alloc in the first place.

But as Alf has pointed out it's all largely academic,
if your program reaches this point you're probably
scuppered anyway, which reinforces my earlier
suggestion of keeping it simple and just letting the
exception propagate out of the ctor.

object could hav been constructed and bad_alloc raised ... after if one or
more members are pointers
For exemple :
class Something {
....
char * m_s[nbr]; // allocated by one of the constructors
....

Something ()
{...}
Something (int sz)
{allocation of m_s...}

}

[Kai-Uwe Bux]

Xavier Serrand wrote:

>
"tragomaskhalos " <da************ *@logicacmg.com a écrit dans le message
de news:11******** **************@ q75g2000hsh.goo glegroups.com.. .

>On 30 Jul, 19:50, "Xavier Serrand" <xxxxxx.xxxx... @xxx.frwrote:

template <typename Tstatic Pile<T* createPile(int sz)
{
Pile<T* pp;
try
{
pp = new Pile<T>(sz);
return pp;
}
catch (std::bad_alloc &)
{
try
{
// clearing what can be cleared ...
// ...
// deleting the instance : the destructor has to be sure
// (may be hard to do...)
pp->~Pile<T>();
}
catch (std::exception & e)
{
// nothing to do
}
return NULL;
}
}

This is wrong isn't it? If bad_alloc is thrown then
the object won't have been constructed, so you don't
want to be calling the destructor on 'pp' - UB and
all that (not to mention the fact that pp is
uninitialise d in this case anyway). In any case,
using new(nothrow) saves you having to mess about
with bad_alloc in the first place.

But as Alf has pointed out it's all largely academic,
if your program reaches this point you're probably
scuppered anyway, which reinforces my earlier
suggestion of keeping it simple and just letting the
exception propagate out of the ctor.

object could hav been constructed and bad_alloc raised ... after if one or
more members are pointers

[snip]

No.

If during evaluation of the expression

new SomeType ( some args )

memory allocation is successful but the constructor call throws (whatever it
may throw) the call to new will not return, the memory will be deallocated
and not leak, and there will not be possible way to do manual clean up
afterwards. For example, in the code above, if

pp = new File<T>( sz )

throws from the call to File<T>, the variable pp will not point to anything
meaningful. In particular, pp->~File<T>() is undefined behavior.
The upshot is: you have to write the constructor for any class in such a way
that it does not leak when subobjects and members cannot be successfully
constructed. Outside the constructor, there is no way to undo the harm that
has been done. In the above example, if File<T>() could fail, it better
fail gracefully (without resource leak) because your proposed trick to
repair things from the outside is bound to fail.

Hint: within constructors, use std::auto_ptr for allocation of multiple
pointer members.

Best

Kai-Uwe Bux

[James Kanze]

On Jul 30, 11:10 pm, tragomaskhalos <dave.du.verg.. [e-mail] >
wrote:

On 30 Jul, 19:50, "Xavier Serrand" <xxxxxx.xxxx... @xxx.frwrote:

template <typename Tstatic Pile<T* createPile(int sz)
{
Pile<T* pp;
try
{
pp = new Pile<T>(sz);
return pp;
}
catch (std::bad_alloc &)
{
try
{
// clearing what can be cleared ...
// ...
// deleting the instance : the destructor has to be sure
// (may be hard to do...)
pp->~Pile<T>();
}
catch (std::exception & e)
{
// nothing to do
}
return NULL;
}
}

This is wrong isn't it? If bad_alloc is thrown then
the object won't have been constructed, so you don't
want to be calling the destructor on 'pp' - UB and
all that (not to mention the fact that pp is
uninitialised in this case anyway). In any case,
using new(nothrow) saves you having to mess about
with bad_alloc in the first place.

But as Alf has pointed out it's all largely academic,
if your program reaches this point you're probably
scuppered anyway, which reinforces my earlier
suggestion of keeping it simple and just letting the
exception propagate out of the ctor.

The problem is that Alf's point doesn't always apply. It
certainly doesn't apply on smaller, embedded systems, which
don't have much memory. And it may not always apply on larger,
general purpose systems: when, for example, the allocations are
due to a particularly complicated user request, it may make
sense to catch bad_alloc at a higher level, and report some sort
of error without bringing down the server. (A lot of protocols
provide for an "insufficie nt resources" error, for example, if
the request is too complicated.)

The real problem if you do want to recover is that you have to
ensure that all of the memory you've already allocated is freed.
The usual answer to this problem is "one pointer per class". A
class which needs a lot of pointers actually uses a lot of
smaller classes. And when bad_alloc (or any other exception)
pops up, the destructors for all of the already constructed
sub-objects are called, freeing the pointers. (Note that the
"smaller classes" can be as simple as boost::scoped_p tr or
std::auto_ptr; if the pointers are in a standard container,
something like boost::shared_p tr may be appropriate, or wrapping
the standard container in a special class---violating the
principle of one pointer per class, but in this case, it works,
because there won't be any uninitialized pointers, ever.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]