By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,501 Members | 2,805 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,501 IT Pros & Developers. It's quick & easy.

Will this leak ? (question on throw statement)

P: n/a
I have a simplistic exception class like so:

class CommException {
public:
CommException(const char *err){ strncpy(msg,err,ERR_MSG_LEN); }
virtual ~CommException(){;}
void erase(void) { memset(msg,'\\0',ERR_MSG_LEN); }
const char* report(void) { return msg ; }

private:
CommException( const CommException&);
CommException& operator= (const CommException&) ;

char msg[ERR_MSG_LEN+1] ;
};
When I use this kinda statement:

throw CommException("Blah, blah, blan") ; //compiler barfs here

Unless I do this:

throw new CommException("Blah, blah, blah") ;
In my catch statement, I have this:

catch (const CommException& e) {
//do something with e
//recvd const *ref*, so I cant 'delete' (maybe this is a an example of
a time that one NEEDS to receive an exception by a pointer?
}

Since I am using the *new* keyword (I still don't know why my compiler
insists on this), I assume I am alloc'ing memory from the heap rather
than the stack - so do I need to free this in my catch statement?
Apr 22 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a


Bit byte wrote:
I have a simplistic exception class like so:

class CommException {
public:
CommException(const char *err){ strncpy(msg,err,ERR_MSG_LEN); }
virtual ~CommException(){;}
void erase(void) { memset(msg,'\\0',ERR_MSG_LEN); }
const char* report(void) { return msg ; }

private:
CommException( const CommException&);
CommException& operator= (const CommException&) ;

char msg[ERR_MSG_LEN+1] ;
};
When I use this kinda statement:

throw CommException("Blah, blah, blan") ; //compiler barfs here

Unless I do this:

throw new CommException("Blah, blah, blah") ;
In my catch statement, I have this:

catch (const CommException& e) {
//do something with e
//recvd const *ref*, so I cant 'delete' (maybe this is a an
example of a time that one NEEDS to receive an exception by a pointer?
}

Since I am using the *new* keyword (I still don't know why my compiler
insists on this), I assume I am alloc'ing memory from the heap rather
than the stack - so do I need to free this in my catch statement?


Just been doing some further reading (thanks to parashift), and I
strongly suspect my compilers insistence on the new keyword is related
to my hidden copy constructor in the CommException class ... (please
correct me if I'm headed down the wrong path though)

Apr 22 '06 #2

P: n/a

Bit byte skrev:
I have a simplistic exception class like so:

class CommException {
public:
CommException(const char *err){ strncpy(msg,err,ERR_MSG_LEN); }
virtual ~CommException(){;}
void erase(void) { memset(msg,'\\0',ERR_MSG_LEN); }
const char* report(void) { return msg ; }

private:
CommException( const CommException&);
CommException& operator= (const CommException&) ;
Why are these private?
char msg[ERR_MSG_LEN+1] ;
};
When I use this kinda statement:

throw CommException("Blah, blah, blan") ; //compiler barfs here
Why does it barf? An exception needs to be copyable. I believe this is
what the barf says.
Unless I do this:

throw new CommException("Blah, blah, blah") ;
This is another expression as the first one - and needs another catch.

In my catch statement, I have this:

catch (const CommException& e) {
//do something with e
//recvd const *ref*, so I cant 'delete' (maybe this is a an example of
a time that one NEEDS to receive an exception by a pointer?
} Will never catch the "new" throw expression
Since I am using the *new* keyword (I still don't know why my compiler
insists on this), I assume I am alloc'ing memory from the heap rather
than the stack - so do I need to free this in my catch statement?


You would - and you would have to catch something else. But fix the
basic problem instead.

/Peter

Apr 22 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.