[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SNACC::SnaccException and CML::ASN::Exception
Good suggestion. We'll combine the CML errors into the shared error
number space in the next version. By eliminating the need to store CML
errors in a different exception class, applications can simply catch
Richard E. Nicholas
Secure Systems Consultant
DigitalNet Government Solutions
From: John Stark [mailto:jas@xxxxxxxxxxxx]
Sent: Tuesday, March 16, 2004 2:11 PM
Subject: SNACC::SnaccException and CML::ASN::Exception
I notice that most of the SFL 2.3 code now throws the exception class
SNACC::SnaccException, which contains an error code, a string and a call
stack, and is defined in SNACC's snaccexcept.h.
However parts of the CML code use a subclass of Snacc::SnaccException
CML::ASN::Exception, which only adds a separate error code of its own.
The CML errors don't occupy the same number space as the other SFL
errors, and as far as I can tell, when a CML::ASN::Exception is thrown
the base SNACC::SnaccException's m_errorCode member is left set to a
Would it not be better to abolish the separate CML::ASN::Exception
subclass, use SNACC::SnaccException throughout, and renumber the CML
error codes into the same number space as the error codes used
elsewhere? This would save all my functions that use SFL having to
contain double catch handlers like:
// code that calls SFL methods ...
catch (CML::ASN::Exception &e)
// cleanup code ...
error_code = static_cast<CML::ASN::Error>(e);
error_string = CMU_GetErrorString(error_code);
catch (SNACC::SnaccException &e)
// duplicated cleanup code ...
error_code = e.m_errorCode();
// my own code to map SFL error codes to strings
Tel: +44 1223 566732
Mobile: +44 7968 110628