c++builder exceptions

[Mihai Oltean]

Hi

I wrote a C++Builder program that throws/catch many exceptions
(let's say 1.000.000/ hours). The problem is that I think that is a
bug in the Borland C++Builder exception handling mechanism.

If I catch an exception with catch(...) the memory is never freed! so
my computer can quickly get memory-exhausted.

Here is the code that generates the problem. In VC++ I don't have this
problem. Neither Delphi. I've managed to solve it somehow (as shown in
the second part), but I think that this is not a solution, mainly
because the program is slower in the second case and I'm not sure that
I catch all exceptions.

Does anybody else has another solution to my problem?

thanks,
mihai


#include <vcl.h>
#pragma hdrstop


//-------------------------------------------------------------------
--------
#pragma argsused
int main(int argc, char* argv[])
{
int a = 4;
int b = 0;
int c;

// the case where the memory is not freed
for (int i = 0; i < 1000000; i++)
try{
c = a/b;
}
catch(...){ // with this I catch all exceptions
c = 1;
}

/*
// the case when the memory is freed
for (int i = 0; i < 1000000; i++)
try{
c = a/b;
}
catch(Exception &e){
c = 1;
e.Free(); //Borland says "never call Free()"!
}
*/
return 0;
}

//-------------------------------------------------------------------
--------

 

[John Harrison]

Hi

I wrote a C++Builder program that throws/catch many exceptions
(let's say 1.000.000/ hours). The problem is that I think that is a
bug in the Borland C++Builder exception handling mechanism.

If I catch an exception with catch(...) the memory is never freed! so
my computer can quickly get memory-exhausted.

Here is the code that generates the problem. In VC++ I don't have this
problem. Neither Delphi. I've managed to solve it somehow (as shown in
the second part), but I think that this is not a solution, mainly
because the program is slower in the second case and I'm not sure that
I catch all exceptions.

Does anybody else has another solution to my problem?

thanks,
mihai


#include <vcl.h>
#pragma hdrstop


//-------------------------------------------------------------------
--------
#pragma argsused
int main(int argc, char* argv[])
{
int a = 4;
int b = 0;
int c;

// the case where the memory is not freed
for (int i = 0; i < 1000000; i++)
try{
c = a/b;
}
catch(...){ // with this I catch all exceptions
c = 1;
}

/*
// the case when the memory is freed
for (int i = 0; i < 1000000; i++)
try{
c = a/b;
}
catch(Exception &e){
c = 1;
e.Free(); //Borland says "never call Free()"!
}
*/
return 0;
}

I think you are not going to get an answer to this problem unless you post
some compilable code.

What is <vcl.h>? It's not part of standard C++. What is Exception? Is it
defined in <vcl.h>? If these two are important to your problem, then you
should ask on a group where they are topical, presumably a Borland group.

Also you should be aware that division by zero does not cause an exception,
it causes undefined behaviour. So if in your real program you are doing a
divide by zero, then the Borland compiler can do what it likes and you have
no reason to complain. It's not a bug, its a feature of C++.

john

 

[Karthik Kumar]

Hi

I wrote a C++Builder program that throws/catch many exceptions
(let's say 1.000.000/ hours). The problem is that I think that is a
bug in the Borland C++Builder exception handling mechanism.

If I catch an exception with catch(...) the memory is never freed! so
my computer can quickly get memory-exhausted.

Here is the code that generates the problem. In VC++ I don't have this
problem. Neither Delphi. I've managed to solve it somehow (as shown in
the second part), but I think that this is not a solution, mainly
because the program is slower in the second case and I'm not sure that
I catch all exceptions.

Does anybody else has another solution to my problem?

thanks,
mihai


#include <vcl.h>

This is a non-standard header.

#pragma hdrstop


//-------------------------------------------------------------------

These preprocessor directives are specific to a
particular implementation. Hence ignoring it.

int main(int argc, char* argv[])
{

We dont use either of them. So never mind to put them here.

int a = 4;
int b = 0;
int c;

// the case where the memory is not freed
for (int i = 0; i < 1000000; i++)

Array indices would better be defined as size_t .


What about the opening brace to signify the beginning
of the block, belonging to this loop ?

try{
c = a/b;

This would result in a divide-by-zero error.
I am not really sure if dividing by zero, results in an
error or an exception.




<-- Code Begins -- >
#include <cstdlib> //EXIT_SUCCESS , system
#include <iostream> //cout, endl
#include <stdexcept> //logic_error

int mydiv(int num, int den);


int main() {
int a = 4;
int b = 0;
int c;

// the case where the memory is not freed
for (size_t i = 0; i < 1000000; i++) {

try {
// c = a/b; // Let me replace it with my custom function
c = mydiv(a, b);
} catch(...){ // with this I catch all exceptions
c = 1;
}
}
std::cout << "Out of the loop " << std::endl;
system("pause");
return EXIT_SUCCESS;
}

int mydiv(int num, int den) {
if (!den) {
throw std::logic_error("Divide by zero");
} else {
return ( num / den ) ;
// Crude integer division that is.
}
}

<-- Code Ends -->

This code ran successfully , in my implementation.
The exception handlers were invoked 1000000 times ( the
same upper bound specified for the loop).

<OT>
I run MinGW.
gcc (GCC) 3.4.2 (mingw-special)
</OT>

 

[Bob Hairgrove]

If I catch an exception with catch(...) the memory is never freed! so
my computer can quickly get memory-exhausted.

This is definitely off-topic in comp.lang.c++, but I will give you the
answer because it is short, and you may have trouble finding it
elsewhere.

This is a known issue with Borland. The solution is: Don't ever use
catch(...). Specify the type of exception, e.g.:

catch(const std::exception &e)
// any of the STL containers might throw this
// or an exception derived from std::exception

or for SEH-type exceptions, which are wrapped by the VCL as Exception:

catch(Exception &e)
// note that you cannot, for some reason,
// catch a const Exception & because of the way
// Borland implements it.

HTH

 

[Mihai Oltean]

Thanks Bob,

The problem if I use:

catch(Exception &e)

is that I have to call e.Free() at the end of catch block. Otherwise
the memory will not be freed. And Borland does not say anything about
that. But if I throw the exception myself and then try to catch it I
don't have to use e.Free() because I get an error!

regards,
mihai

 

[Verne]

I'm extremely new here and not done much to speak of with windows C++
but seems you speak of the same Borland Builder that I'm playing with.
I've just finished the Tutorial on making their small Editor. Yes,
finished and flunked it because they give a bad line in the Save
Command. I've dropped them a line but......???? Did you find the
answer to this one?

I've done a lot of work with VB so have some experience with that and
C and such for years off and on plus a lot of C++ for dos which simply
doens't hit it any longer with XP and on.

Verne