BorlandTalk.com

Sally · Guest

The following code seems to have a Borland Bug in it, or is it that I'm
doing something that is not officially "allowed"? Then again, I can't
imagine why NESTED try/finally wouldn't be allowed within a finally
loop.

SITUATION: just 1 exception thrown, finally block has try-finally blocks
inside it nested 2 deep.
EXPECTATION: test1 and test2 should end up 0 (test1-- and test2-- both
run), imagine they are locks
PROBLEM: test2-- never runs, the function exits to the caller's
exception handlers right after "test1--"

_______________________________________
void __fastcall testForBorlandBug(void) {
long ignored=0;
long test1 = 0;
long test2 = 0;

try {
throw Eanything;
} __finally {

test2++;
try {
test1++;
try {
ignored++;
} __finally {
test1--;
}

} __finally {
test2--;
}

}
}

Vladimir Stefanovic · Guest

'__finally' is not a C++ keyword (it's just an extension), and
it has many issues that has already been reported. Most of the
problems come from nested try/finally statements.

I have alredy shown some cases in these NGs when try/finally
behaves unexpectedly.

You can consider redesigning your code or use the RAII design
pattern to secure some 'finally' tasks to be guaranteed
executed....

"Sally" <nospamforme (AT) spamme (DOT) com> wrote:

Vladimir Stefanovic · Guest

Also, look here:
http://tinyurl.com/9god4

"Sally" <nospamforme (AT) spamme (DOT) com> wrote:

Andrue Cope [TeamB] · Guest

Don't use __finally. It is a proprietary extension so it does whatever
Borland think it should do. Historically it has suffered many bugs and
BCB4 will certain contain a number of them.

The C++ language doesn't actually need a __finally construct. The job
can be done using the RAII paradigm. The language guarantees that any
object created on the stack will be automatically destroyed when the
stack unwinds. For a class this means guaranteed calling of the ctor
and dtor.

Your example is of course contrived but I think the following would be
the RAII equivalent. If nothing else it would be worth stepping through
the code line by line to see what happens. In particular note what
happens at the '}'s.

class TIncDec
{
long & Counter;
public:
TIncDec( long & TheCounter )
: Counter( TheCounter )
{
++Counter; // NB:Putting '++' in front may be more efficient
}

~TIncDec()
{
--Counter;
}
};

void __fastcall testForBorlandBug(void)
{
long ignored=0,
test1=0,
test2=0;

TIncDec id2( test2 );

{
TIncDec id1( test1 );

{
++ignored;
}
}
}
--
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html

Serge Skorokhodov · Guest

Vladimir Stefanovic wrote:

<skip>

Alisdair Meredith [TeamB] · Guest

Serge Skorokhodov wrote:

Sally · Guest

Thank you for the several confirmations that this is a Borland Bug. Bug
can anyone tell me if THIS bug is still in the newest version of
C++Builder (I believe CB6?)

Basically, my current workaround is to not use more than 1 level of
nesting WITHIN a finally loop. Not ideal but...

Frankly the RAII method is reliable but tediously horrible. I have about
2000 finally blocks in my program, and if I had to create objects for
each and every one I would go crazy. Particularly when you consider it
is much harder to read back code with RAII.

I have found several __finally bugs (most annoying is that they don't
always run when you use "return" statements)... but I'd still rather
work around all the bugs than switch to RAII.

Blah, Borland, FIX THE __FINALLY STUFF *PLEASE*.

Vladimir Stefanovic · Guest

Andrue Cope [TeamB] · Guest

Sally wrote:

Hendrik Schober · Guest

Sally <nospamforme (AT) spamme (DOT) com> wrote:

Chris Uzdavinis (TeamB) · Guest

"Sally" <nospamforme (AT) spamme (DOT) com> writes:

Chris Uzdavinis (TeamB) · Guest

"Hendrik Schober" <SpamTrap (AT) gmx (DOT) de> writes:

Hendrik Schober · Guest

Chris Uzdavinis (TeamB) <chris (AT) uzdavinis (DOT) com> wrote:

Chris Uzdavinis (TeamB) · Guest

"Hendrik Schober" <SpamTrap (AT) gmx (DOT) de> writes:

Ed Mulroy · Guest

The debugger and a usable IDE also make it compelling. Back when Borland
C++ was current the project manager was also a compelling item, very
powerful and not equaled by anyone since.

.. Ed