By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,804 Members | 1,618 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,804 IT Pros & Developers. It's quick & easy.

Exception Handling & Memory Leak

P: n/a
Hello,

I am a specific problem in exception handling. The code snippets is
attached below.

void f()
{
char *ptr = new char(20);
throw 2;
}

void main(void)
{
try
{
f();
}
catch(...)
{
}
}

The above function calls shows that a memory has been allocated to
char * pointer. With the throw statment in the subsequent line states
that there will be memory leak in this time of situation. I just
wanted to know is there any method to free the memory allocated in the
catch(...) block.

Regards
Bikash
Jul 22 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
finnaly()
{
}

or use deconstructor .
Jul 22 '05 #2

P: n/a

"Bikash" <b_**********@hotmail.com> wrote in message
news:d2**************************@posting.google.c om...
Hello,

I am a specific problem in exception handling. The code snippets is
attached below.

void f()
{
char *ptr = new char(20);
throw 2;
}

void main(void)
{
try
{
f();
}
catch(...)
{
}
}

The above function calls shows that a memory has been allocated to
char * pointer. With the throw statment in the subsequent line states
that there will be memory leak in this time of situation. I just
wanted to know is there any method to free the memory allocated in the
catch(...) block.


No there isn't.

Don't use raw pointers, put your pointers in classes instead. Classes can
have destructors and so can free the memory of any pointers they hold.

john
Jul 22 '05 #3

P: n/a
Bikash wrote:
Hello,

I am a specific problem in exception handling. The code snippets is
attached below.

void f()
{
char *ptr = new char(20);
throw 2;
}

void main(void)
{
try
{
f();
}
catch(...)
{
}
}

The above function calls shows that a memory has been allocated to
char * pointer. With the throw statment in the subsequent line states
that there will be memory leak in this time of situation. I just
wanted to know is there any method to free the memory allocated in the
catch(...) block.


If it is acceptable that the memory is freed when the f() is left via an
exception (i.e. before it enters the catch(...) block) you could use
std::auto_ptr class or a more sophisticated smart pointer like the ones
in the boost library (http://boost.org/). You may also want look at the
RAII idiom, this idiom is essential if you want to write exception safe
code.
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl
Jul 22 '05 #4

P: n/a
rokia wrote:
finnaly()
{
}

Even though many compilers support it 'finally' is not standard C++.
However the RAII idiom is an excellent alternative for finally.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl
Jul 22 '05 #5

P: n/a
In article <d2**************************@posting.google.com >,
b_**********@hotmail.com (Bikash) wrote:
Hello,

I am a specific problem in exception handling. The code snippets is
attached below.

void f()
{
char *ptr = new char(20);
throw 2;
}

void main(void)
{
try
{
f();
}
catch(...)
{
}
}

The above function calls shows that a memory has been allocated to
char * pointer. With the throw statment in the subsequent line states
that there will be memory leak in this time of situation. I just
wanted to know is there any method to free the memory allocated in the
catch(...) block.


There would be a memory leak in any case because no part of the code
even makes the attempt to delete the memory allocated... Maybe a more
resonable example?

void function_that_may_throw();

int main() {
try {
char* ptr = new char( 20 );
function_that_may_throw();
delete ptr;
}
catch ( ... ) { }
}

In this, the solution is to use an auto_ptr:

int main() {
try {
auto_ptr<char> ptr( new char( 20 ) );
function_that_may_throw();
}
catch ( ... ) { }
}

Other examples may call for other solutions, but in all casses RAII is
the way to go. Do a google search on "RAII".
Jul 22 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.