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]

Re: c++builder exceptions


"Mihai Oltean" <mihaioltean@ya hoo.com> wrote in message
news:4e6cae02.0 410062218.7bf1b a3c@posting.goo gle.com...[color=blue]
> 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;
> }[/color]

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]

Re: c++builder exceptions

Mihai Oltean wrote:[color=blue]
> 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>[/color]

This is a non-standard header.
[color=blue]
> #pragma hdrstop
>
>
> //-------------------------------------------------------------------
> --------
> #pragma argsused[/color]

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

[color=blue]
> int main(int argc, char* argv[])
> {[/color]

We dont use either of them. So never mind to put them here.
[color=blue]
> int a = 4;
> int b = 0;
> int c;
>
> // the case where the memory is not freed
> for (int i = 0; i < 1000000; i++)[/color]

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 ?
[color=blue]
> try{
> c = a/b;[/color]

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_erro r("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>

--
Karthik.

[Bob Hairgrove]

[OT]Re: c++builder exceptions

On 6 Oct 2004 23:18:20 -0700, mihaioltean@yah oo.com (Mihai Oltean)
wrote:
[color=blue]
>If I catch an exception with catch(...) the memory is never freed! so
>my computer can quickly get memory-exhausted.[/color]

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

--
Bob Hairgrove
NoSpamPlease@Ho me.com

[Mihai Oltean]

Re: [OT]Re: c++builder exceptions

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

Bob Hairgrove <invalid@bigfoo t.com> wrote in message news:<ph7am0pf3 ij941nidei9nem3 jf5cjomv0i@4ax. com>...[color=blue]
> On 6 Oct 2004 23:18:20 -0700, mihaioltean@yah oo.com (Mihai Oltean)
> wrote:
>[color=green]
> >If I catch an exception with catch(...) the memory is never freed! so
> >my computer can quickly get memory-exhausted.[/color]
>
> 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[/color]

[Verne]

Re: [OT]Re: c++builder exceptions

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


On 7 Oct 2004 23:55:02 -0700, mihaioltean@yah oo.com (Mihai Oltean)
wrote:
[color=blue]
>Thanks Bob,
>
>The problem if I use:
>
>catch(Exceptio n &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
>
>Bob Hairgrove <invalid@bigfoo t.com> wrote in message news:<ph7am0pf3 ij941nidei9nem3 jf5cjomv0i@4ax. com>...[color=green]
>> On 6 Oct 2004 23:18:20 -0700, mihaioltean@yah oo.com (Mihai Oltean)
>> wrote:
>>[color=darkred]
>> >If I catch an exception with catch(...) the memory is never freed! so
>> >my computer can quickly get memory-exhausted.[/color]
>>
>> 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[/color][/color]