Board index » cppbuilder » Multiple usasge of try{} / __finally{} needfull....?

Multiple usasge of try{} / __finally{} needfull....?


2005-08-11 06:17:13 AM
cppbuilder41
dear builders,
is there any reason, why i should use here two try{} / __finally{}
blocks....?
thanks to any suggestions...
Oren
/********************************************************/
int OldEventMask = rePreview->Perform(EM_SETEVENTMASK, 0, 0);
try
{
Screen->Cursor = crHourGlass;
try
{
rePreview->Lines->Assign(Results.get());
}
__finally
{
Screen->Cursor = crDefault;
}
}
__finally
{
rePreview->Perform(EM_SETEVENTMASK, 0, OldEventMask);
}
/********************************************************/
------->OR can i reduce it to only one ? like this.....
/********************************************************/
int OldEventMask = rePreview->Perform(EM_SETEVENTMASK, 0, 0);
try
{
Screen->Cursor = crHourGlass;
rePreview->Lines->Assign(Results.get());
}
__finally
{
rePreview->Perform(EM_SETEVENTMASK, 0, OldEventMask);
Screen->Cursor = crDefault;
}
//by the way "Results" is:
std::auto_ptr<TStringList>Results(new TStringList);
/********************************************************/
 
 

Re:Multiple usasge of try{} / __finally{} needfull....?

It's proven that nested 'try/__finally' statements in BCB
can behave as you do *not* expect. '__finally' is not
a C++ keyword and AFAIKworks fine with Delphi only.
There were some threads recetly on that issue.
Try to use only one '__finally' for which I havent
noticed any issues.
Also look ar RAII design pattern.
--
Best regards,
Vladimir Stefanovic
"Oren Halvani" < XXXX@XXXXX.COM >wrote in message
Quote
dear builders,

is there any reason, why i should use here two try{} / __finally{}
blocks....?

thanks to any suggestions...


Oren

/********************************************************/
int OldEventMask = rePreview->Perform(EM_SETEVENTMASK, 0, 0);

try
{
Screen->Cursor = crHourGlass;
try
{
rePreview->Lines->Assign(Results.get());
}
__finally
{
Screen->Cursor = crDefault;
}
}
__finally
{
rePreview->Perform(EM_SETEVENTMASK, 0, OldEventMask);
}
/********************************************************/

------->OR can i reduce it to only one ? like this.....

/********************************************************/
int OldEventMask = rePreview->Perform(EM_SETEVENTMASK, 0, 0);

try
{
Screen->Cursor = crHourGlass;
rePreview->Lines->Assign(Results.get());
}
__finally
{
rePreview->Perform(EM_SETEVENTMASK, 0, OldEventMask);
Screen->Cursor = crDefault;
}

//by the way "Results" is:

std::auto_ptr<TStringList>Results(new TStringList);
/********************************************************/


 

Re:Multiple usasge of try{} / __finally{} needfull....?

"Oren Halvani" < XXXX@XXXXX.COM >wrote in message
Quote
is there any reason, why i should use here two try{} / __finally{}
blocks....?
In this specific case, no. Setting the Cursor property does not throw an
exception, so there is no need for the extra set of try/finally blocks since
the resetting of the event mask will not be skipped. If the the Cursor
property were to throw an exception, then the extra set would be needed.
Quote
------->OR can i reduce it to only one ? like this.....
You could.
Another way is to not use try/finally at all. Use the same RAII approach
that std::auto_ptr uses:
struct EventMaskGuard
{
int OldEventMask;
TCustomRichEdit *RE
EventMaskGuard(TCustomRichEdit *RichEdit, int NewEventMask = 0)
OldEventMask(0), RE(RichEdit)
{
if( RE )
OldEventMask = RE->Perform(EM_SETEVENTMASK, 0,
NewEventMask);
}
~EventMaskGuard()
{
if( RE )
RE->Perform(EM_SETEVENTMASK, 0, OldEventMask);
}
};
struct ScreenCursorGuard
{
TCursor OldCursor;
ScreenCursorGuard(TCursor NewCursor)
{
OldCursor = Screen->Cursor;
Screen->Cursor = NewCursor;
}
~ScreenCursorGuard()
{
Screen->Cursor = OldCursor;
}
};
{
//...
EventMaskGuard g(rePreview);
ScreenCursorGuard g(crHourGlass);
rePreview->Lines->Assign(Results.get());
//...
}
Gambit
 

{smallsort}

Re:Multiple usasge of try{} / __finally{} needfull....?

WOW :-)
thanks alot Remy and of course you too Vlad !!
Oren
 

Re:Multiple usasge of try{} / __finally{} needfull....?

"Vladimir Stefanovic" < XXXX@XXXXX.COM >wrote in message
Quote
It's proven that nested 'try/__finally' statements
in BCB can behave as you do *not* expect.
That only applies when you have nested try...catch and try..finally blocks
working together.
Gambit
 

Re:Multiple usasge of try{} / __finally{} needfull....?

Oren Halvani wrote:
Quote
thanks to any suggestions...
// Temporarily activate the hourglass cursor.
class TOGeneral_RAII_HourGlass
{
static HourGlassCounter;
public:
TOGeneral_RAII_HourGlass()
{
++HourGlassCounter;
Screen->Cursor=crHourGlass;
}
~TOGeneral_RAII_HourGlass()
{
if( HourGlassCounter )
--HourGlassCounter;
if( !HourGlassCounter )
Screen->Cursor=crDefault;
}
};
/////////
{
TOGeneral_RAII_HourGlass hg;
rePreview->Lines->Assign( Results.get() );
} // Hourglass ends here.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Multiple usasge of try{} / __finally{} needfull....?

Andrue Cope [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
Oren Halvani wrote:

>thanks to any suggestions...

// Temporarily activate the hourglass cursor.
class TOGeneral_RAII_HourGlass
{
static HourGlassCounter;
public:
TOGeneral_RAII_HourGlass()
{
++HourGlassCounter;

Screen->Cursor=crHourGlass;
}
~TOGeneral_RAII_HourGlass()
{
if( HourGlassCounter )
What's this 'if' statement for?
Quote
--HourGlassCounter;

if( !HourGlassCounter )
Screen->Cursor=crDefault;
}
};
[...]
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett
 

Re:Multiple usasge of try{} / __finally{} needfull....?

Hendrik Schober wrote:
Quote
>if( HourGlassCounter )

What's this 'if' statement for?
Paranoia :)
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Multiple usasge of try{} / __finally{} needfull....?

Andrue Cope [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
Hendrik Schober wrote:

>>if( HourGlassCounter )
>
>What's this 'if' statement for?

Paranoia :)
I'd accept an assertion, because if it
triggers, this would uncover a serious
bug. But since the 'if' would just help
to hide such a bug, I wouldn't call it
paranoia, but sloppiness.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett