exception handling .. more
ma740988_at_pegasus.cc.ucf.edu
Date: 12/31/04
- Next message: Jonathan Mcdougall: "Re: exception handling .. more"
- Previous message: Ulrich Eckhardt: "Re: strcat"
- Next in thread: Jonathan Mcdougall: "Re: exception handling .. more"
- Reply: Jonathan Mcdougall: "Re: exception handling .. more"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 30 Dec 2004 20:34:39 -0800
Volume II, first chapter of the text thinking in C++ seem to indicate
that one ought to use error handling - ie throw an exception - instead
of using a host of return statements.
So now consider:
class some_exception : public std::runtime_exception {
{
some_exception ( const std::string& msg)
throw () : usrMsg(msg) { }
~some_exception ( )
throw () { }
const char *what() const throw() { return usrMsg.c_str(); }
private:
std::string usrMsg;
};
// now use some_exception
class enet_connection : public some_exception
{
public:
enet_connection() { }
~enet_connection() { }
void connect ( /args/ ) throw()
{
if ( ... )
throw some_exception ( " oops 1 " ) ;
}
void send ( /args/ ) throw()
{
if ( ... )
throw some_exception ( " oops 2 " ) ;
}
};
//Similarily
class slink_connection : public some_exception
{
};
For the purposes of discussion class enet_connection and
slink_connection refer to communication links. i.e ethernet and
starlink.
Now we're ready.
/////////////////////
class main_class
{
main_class()
: p_enet(new enet_connection()) //// 2 ////
, p_slink(new slink_connection()) //// 2 ////
{ }
void do_work()
{
try
{
p_enet->send( /args/ );
}
catch ( some_exception& excep ) { }
}
private
enet_connection* p_enet;
slink_connection* p_slink;
};
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
If memory serves me well, the C++ FAQ's warns against the lines/items
marked //// 2 ////. The specifics I dont recall but the basic
premise surrounds the fact that the TWO (one class if I recall would be
ok ) classes (enet_connection & slink_connection) throw exceptions
which could potentiall lead to disaster when viewed in terms of
construction and 'destruction/cleanup'.
With that in mind, would it be safe to state that an alternative would
be to revise the main_class to pass in the fully constructed p_slink
and p_enet objects? So now:
int main ()
{
try {
slink_connection* p_slink = new slink_connection();
}
catch (some_exception& excep) { }
// similarily
try {
enet_connection* p_enet = new enet_connection();
}
catch ( some_exception& excep) { }
// then later
main_class* p_main_class = new main_class ( p_slink, p_enet );
}
In the end, I might have to revise the code since my advisor is not a
fan of exceptions and advises against them.
//// 2 ////
I dont recall in my readings the need to initialize a pointer to NULL
in the constructor, and check for NULL existence in the destructor.
i.e
class my_class {
public:
my_class()
: ptr_testa(NULL), ptr_testb(NULL)
{
ptr_testa = new test_classA();
prt_testb = new test_classB();
}
~my_class()
{
if (ptr_testa != NULL)
delete ptr_testa;
if (ptr_testb != NULL)
delete ptr_testb;
}
private:
test_classA* ptr_testa;
test_classB* ptr_testb;
};
Intutively this amounts to good coding style and in C++ land zero would
be preferred as opposed to null. Correct?
Just clarifying.
- Next message: Jonathan Mcdougall: "Re: exception handling .. more"
- Previous message: Ulrich Eckhardt: "Re: strcat"
- Next in thread: Jonathan Mcdougall: "Re: exception handling .. more"
- Reply: Jonathan Mcdougall: "Re: exception handling .. more"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|