A Frequently-Asked-Question (FAQ) about ACE's logging
macros is "What's the difference between
ACE_DEBUG and ACE_ERROR? Can I use
LM_DEBUG severity with ACE_ERROR and
vice-versa?" Riverace's support customers can see the answer
to this and other ACE FAQs in the support
Knowledge Base. Everyone else will have to keep
reading...
The difference between ACE_DEBUG and
ACE_ERROR is what happens to the calling thread's
ACE_Log_Msg instance's op_status
indicator. ACE_ERROR sets op_status
to -1; ACE_DEBUG sets it to 0.
op_status is sometimes used to tell what the
status of the most recent ACE call was. This can be most
helpful when detecting if there was an error in a constructor,
which can't return a value. For example:
ACE_INET_Addr bad ("bad.address.given");
if (ACE_LOG_MSG::op_status () == -1)
// take error action
op_status can be accessed directly via
ACE_LOG_MSG::op_status (), as above, and it can
also be inserted into a log message using the %R
logging directive.
This scheme relies on the method in question setting
op_status() before return; inside of ACE, this is
most often done by using the ACE_ERROR macro when
an error occurs. Even if the particular logging severity is
disabled, op_status will still be set, unless
logging macros are defined to no-ops via the
ACE_NLOGGING configuration macro (see APG chapter
3 for details).
As we see above, there are some significant drawbacks
to using op_status as a serious error detection
facility. It relies on methods using ACE_ERROR to
set the status, and is disabled completely when
ACE_NLOGGING is set. It's much better to use
value-returning methods in ACE and exceptions in your
application code.
So what's the recommended use for ACE_ERROR
and ACE_DEBUG in your code? The best way to use
them is as indicators to readers of your code that an error
is, or isn't, being reported.