471,612 Members | 2,430 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,612 software developers and data experts.

Testing ScopeGuard from CUJ article: SG destructor not called on exceptions??

Hi,

I wrote a small test script to utilize the ScopeGuard class from the
Dec 2000 CUJ article.

I noted that my cleanup function was being called on normal block
exit, but not on calling a function I wrote to throw an exception.

#include <iostream>
#include <exception>
#include "ScopeGuard.h"

using namespace std;

void CloseFile(FILE* file)
{
cout << "Closing file" << endl;
fclose(file);
cout << "Closed file" << endl;
}

void Throw(void)
{
throw std::exception();
}

int testScopeGuard (void)
{
//Open a file that we don't intend to close
FILE* file = fopen("abc.txt", "a+");
ON_BLOCK_EXIT(CloseFile, file);
cout << "Guard made" << endl;
Throw();
}

When I comment out the Throw() call, the function CloseFile is called
and I do get a log like :
Guard made
Closing file
Closed file

However, when I leave the Throw() call in, I get a log like:
Guard made
Aborted (core dumped)

I am using g++ on cygwin :
bash-2.05b$ g++ --version
g++ (GCC) 3.3.1 (cygming special)

Does this mean that on encountering an exception, the ScopeGuard
object made by ON_BLOCK_EXIT is not being destroyed?

Regards,
Vikram
Jul 22 '05 #1
6 1546

"Vikram Paranjape" <us***********@spamgourmet.com> wrote in message
news:16**************************@posting.google.c om...
Hi,

I wrote a small test script to utilize the ScopeGuard class from the
Dec 2000 CUJ article.

I noted that my cleanup function was being called on normal block
exit, but not on calling a function I wrote to throw an exception.

#include <iostream>
#include <exception>
#include "ScopeGuard.h"

using namespace std;

void CloseFile(FILE* file)
{
cout << "Closing file" << endl;
fclose(file);
cout << "Closed file" << endl;
}

void Throw(void)
{
throw std::exception();
}

int testScopeGuard (void)
{
//Open a file that we don't intend to close
FILE* file = fopen("abc.txt", "a+");
ON_BLOCK_EXIT(CloseFile, file);
cout << "Guard made" << endl;
Throw();
}

When I comment out the Throw() call, the function CloseFile is called
and I do get a log like :
Guard made
Closing file
Closed file

However, when I leave the Throw() call in, I get a log like:
Guard made
Aborted (core dumped)

I am using g++ on cygwin :
bash-2.05b$ g++ --version
g++ (GCC) 3.3.1 (cygming special)

Does this mean that on encountering an exception, the ScopeGuard
object made by ON_BLOCK_EXIT is not being destroyed?


I think its much more likely that either your implementation has a bug, or
gcc 3.3.1 has a bug.

I suggest that you post a complete compilable example, this is the best way
to get help with code that doesn't work. See the FAQ
http://www.parashift.com/c++-faq-lit...t.html#faq-5.8.

john
Jul 22 '05 #2

"John Harrison" <jo*************@hotmail.com> wrote in message
news:c1*************@ID-196037.news.uni-berlin.de...
I suggest that you post a complete compilable example, this is the best way to get help with code that doesn't work. See the FAQ
http://www.parashift.com/c++-faq-lit...t.html#faq-5.8.


Sorry about that (should have proofread the post before clicking the send
button) :-)
I am using the Scopeguard.h file as is from the CUJ article.
The compilable code is as follows (I missed the main function in my last
post):

#include <iostream>
#include <exception>
#include "ScopeGuard.h"

using namespace std;

void CloseFile(FILE* file)
{
cout << "Closing file" << endl;
fclose(file);
cout << "Closed file" << endl;
}

void Throw(void)
{
throw std::exception();
}

int testScopeGuard (void)
{
//Open a file that we don't intend to close
FILE* file = fopen("abc.txt", "a+");
ON_BLOCK_EXIT(CloseFile, file);
cout << "Guard made" << endl;
//Throw();
}

int main (void)
{
return testScopeGuard();
}

Jul 22 '05 #3
* us***********@spamgourmet.com (Vikram Paranjape) schriebt:

I wrote a small test script to utilize the ScopeGuard class from the
Dec 2000 CUJ article.

I noted that my cleanup function was being called on normal block
exit, but not on calling a function I wrote to throw an exception.

#include <iostream>
#include <exception>
#include "ScopeGuard.h"

using namespace std;

void CloseFile(FILE* file)
{
cout << "Closing file" << endl;
fclose(file);
cout << "Closed file" << endl;
}

void Throw(void)
{
throw std::exception();
}

int testScopeGuard (void)
{
//Open a file that we don't intend to close
FILE* file = fopen("abc.txt", "a+");
ON_BLOCK_EXIT(CloseFile, file);
cout << "Guard made" << endl;
Throw();
Insert dummy 'return 0;' here to satisfy comp
}

When I comment out the Throw() call, the function CloseFile is called
and I do get a log like :
Guard made
Closing file
Closed file

However, when I leave the Throw() call in, I get a log like:
Guard made
Have you tried catching the exception in main?

It might be that the std::cout isn't flushed like it should be.
Aborted (core dumped)

I am using g++ on cygwin :
bash-2.05b$ g++ --version
g++ (GCC) 3.3.1 (cygming special)
With MingW g++ 3.2.3 and exception catching in main there is seemingly no
problem:
C:\...\test> g++ --version
g++ (GCC) 3.2.3 (mingw special 20030504-1)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
C:\...\test> g++ -pedantic -ansi -o main.exe main.cpp

C:\...\test> main
Guard made
Closing file
Closed file
! St9exception

C:\...\test> _
It also compiles and runs fine with Visual C++ 7.1, when the appropriate
fix for the MSVC compiler bug is made in [ScopeGuard.h], namely
#ifdef _MSC_VER
#define ANONYMOUS_VARIABLE(str) CONCATENATE(str, __COUNTER__)
#else
#define ANONYMOUS_VARIABLE(str) CONCATENATE(str, __LINE__)
#endif

Does this mean that on encountering an exception, the ScopeGuard
object made by ON_BLOCK_EXIT is not being destroyed?


Probably not.

Try a debugger, try catching that exception in main.

Jul 22 '05 #4
* al***@start.no (Alf P. Steinbach) schriebt:

Have you tried catching the exception in main?


Sorry, I didn't think: without catching that exception somewhere you
are _not_ guaranteed anything other than possibly a call to std::terminate;
in particular, you're not guaranteed stack cleanup.

Jul 22 '05 #5
Works fine on my copy of gcc 3.3.1 (also cygwin).

john
Jul 22 '05 #6

"Alf P. Steinbach" <al***@start.no> wrote in message
news:40****************@news.individual.net...
* al***@start.no (Alf P. Steinbach) schriebt:

Have you tried catching the exception in main?
Sorry, I didn't think: without catching that exception somewhere you
are _not_ guaranteed anything other than possibly a call to

std::terminate; in particular, you're not guaranteed stack cleanup.


Now that makes sense to me. I wrote both versions of main 1. without the
enclosing try-catch block and 2. with the said block
and found that the version with the try catch block was correctly calling
the cleanup code.

So, I guess, the moral is ScopeGuard alone isn't really the silver bullet
for handling cleanup in the presence of exceptions.
It is extremely useful however, if the main() is enclosed in a try catch
block (and in a multithreaded environment, the entry function for each
thread is enclosed in a try catch block). ScopeGuard is still very useful,
though, becuase you can now be sure exceptions won't leave the threads in an
unpredictable state at each branch in the code where temporaries are being
created (if you used the appropriate SG functionality).

I guess I missed the necessity of the enclosing try..catch block in the CUJ
article.

Thanks a lot , John and Alf. for your help.

Regards,
Vikram
Jul 22 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by Timothy Madden | last post: by
13 posts views Thread by Radde | last post: by
13 posts views Thread by Peter Hemmingsen | last post: by
35 posts views Thread by Peter Oliphant | last post: by
14 posts views Thread by gurry | last post: by
17 posts views Thread by Phlip | last post: by
4 posts views Thread by Subra | last post: by
1 post views Thread by XIAOLAOHU | last post: by
reply views Thread by leo001 | last post: by
1 post views Thread by ZEDKYRIE | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.