issue 1
(Code review - bad practice, exit(1) in utility class) commented on by xianggenw
- Yes, it is better to propagate the bad_alloc exception to the outer code for logging
or recovery things. I will fix this problem in the next revision. Thanks
Yes, it is better to propagate the bad_alloc exception to the outer code for logging
or recovery things. I will fix this problem in the next revision. Thanks
May 22, 2009
issue 1
(Code review - bad practice, exit(1) in utility class) reported by z...@zoltran.com
- in BigInt.cpp:
BigInt::BigInt(int n) : mem_(1)
{
try { num_ = new char[INITIAL] ; } catch( ... )
{
cerr << "Memory Allocation Error!" << endl ; exit(1) ;
}
Since this should be a reusable component, the exception handling does not
make much sense.
the exception should be let to go up to the application. This way the
application has the flexibility to do more, like eventual recovery or exit
with another exit code or log another message...
in BigInt.cpp:
BigInt::BigInt(int n) : mem_(1)
{
try { num_ = new char[INITIAL] ; } catch( ... )
{
cerr << "Memory Allocation Error!" << endl ; exit(1) ;
}
Since this should be a reusable component, the exception handling does not
make much sense.
the exception should be let to go up to the application. This way the
application has the flexibility to do more, like eventual recovery or exit
with another exit code or log another message...
