Noisy "first-chance exception" message

[Kenneth Porter]

How can I silence this message in the output window for an "expected"
exception?

I have a cache class that throws a cache miss exception when a query fails
to find a cached value. This is caught by the cache client which then
fetches the value from a remote device over a slow link. During application
startup most queries are expected to miss the cache, so the output log
fills with the "first-chance exception" message.

I'm using VS2005 SP1 and also VC6.

[Alex Blekhman]

Post by Kenneth Porter
How can I silence this message in the output window for an
"expected"
exception?

You cannot. On the contrary, you want to know about every
exception that happened in the program.

Post by Kenneth Porter
I have a cache class that throws a cache miss exception when a
query fails
to find a cached value. This is caught by the cache client which then
fetches the value from a remote device over a slow link. During application
startup most queries are expected to miss the cache, so the
output log
fills with the "first-chance exception" message.

This is a common mistake when exceptions are used instead of
return codes. Naturally the output is cluttered with irrelevant
exceptions because exceptions is not the right mechanism to handle
such situation. If exception happens in the code, then it's a sign
that something exceptional occured (usually an error). That's why
the debugger pays special attention to any exception during
execution flow.

"How do I use exceptions?"
http://www.research.att.com/~bs/bs_faq2.html#exceptions

"[17.12] Exception handling seems to make my life more difficult;
clearly I'm not the problem, am I??"
http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.12

HTH
Alex

[Kenneth Porter]

Post by Alex Blekhman
This is a common mistake when exceptions are used instead of
return codes. Naturally the output is cluttered with irrelevant
exceptions because exceptions is not the right mechanism to handle
such situation. If exception happens in the code, then it's a sign
that something exceptional occured (usually an error). That's why
the debugger pays special attention to any exception during
execution flow.

In my case, a cache miss *is* an exceptional condition. It's just the
nature of caches that it happens a lot during initialization, and the
noise can drown out "real" exceptions.

It's nice that the debugger can report an exception, but it shouldn't
force that on me, any more than it should report every non-zero OS API
return code.

Contrast:

#if USE_MISS_EXCEPTION

double getRegister(unsigned registerIndex)
{
try {
return settingsCache.getSetting(registerIndex);
} catch (SettingsCache::Miss&) {
return getRegisterUncached(registerIndex);
}
}

#else

double getRegister(unsigned registerIndex)
{
double value;
const bool miss = settingsCache.getSetting(registerIndex, &value);
if (miss)
value = getRegisterUncached(registerIndex);
return value;
}

#endif

[Alex Blekhman]

Post by Kenneth Porter
In my case, a cache miss *is* an exceptional condition. It's
just the
nature of caches that it happens a lot during initialization,
and the
noise can drown out "real" exceptions.

That's my point exactly. The moment you start to distinguish
between "real" exceptions and "as if" exceptions you should stop
and think why you're in this situation. Because there is no such
distinction. An exception is an exception, end of story.

Post by Kenneth Porter
It's nice that the debugger can report an exception, but it
shouldn't
force that on me, any more than it should report every non-zero OS API
return code.

But is doesn't force you. It's natural that developer wants to see
all exceptions in his code. It's like saying that you don't want
to see access violation message box because it's annoying. The
message box there is for a reason.

Post by Kenneth Porter
double getRegister(unsigned registerIndex)
{
try {
return settingsCache.getSetting(registerIndex);
} catch (SettingsCache::Miss&) {
return getRegisterUncached(registerIndex);
}
}

Consider this code:

double getRegister(unsigned registerIndex)
{
try {
return getRegisterCached(registerIndex);
} catch (SettingsCache::Error& e) {
logError(e);
throw;
}
}

double getRegisterCached(unsigned registerIndex)
{
double value;
if (!settingsCache.getSetting(registerIndex, &value)) {
value = getRegisterUncached(registerIndex);
settingsCache.updateSetting(registerIndex, value);
}

return value;
}


Alex

[Kenneth Porter]

Post by Alex Blekhman
But is doesn't force you. It's natural that developer wants to see
all exceptions in his code. It's like saying that you don't want
to see access violation message box because it's annoying. The
message box there is for a reason.

Are you saying that a C++ exception should always be treated as a fatal
error that can't be handled by code, similar to an assert in C? That seems
to be the point of the "in your face" way the debugger handles them.

[Ondrej Spanel]

Post by Kenneth Porter
Are you saying that a C++ exception should always be treated as a fatal
error that can't be handled by code, similar to an assert in C? That seems

You are not talking C++ exceptions here, but a structured ones, which as
a somewhat different sort. If C++ exceptions would be spilling into the
logs, that would be really a nightmare.

I agree with you sometimes there are situations where structured
exceptions are a good way to do something, but such situations are rare
and not encountered by most developers frequently, which is perhaps why
current behaviour is acceptable by most of us.

Cheers
Ondrej

Post by Kenneth Porter

Post by Alex Blekhman
But is doesn't force you. It's natural that developer wants to see
all exceptions in his code. It's like saying that you don't want
to see access violation message box because it's annoying. The
message box there is for a reason.

Are you saying that a C++ exception should always be treated as a fatal
error that can't be handled by code, similar to an assert in C? That seems
to be the point of the "in your face" way the debugger handles them.

[Ben Voigt [C++ MVP]]

Post by Ondrej Spanel

Post by Kenneth Porter
Are you saying that a C++ exception should always be treated as a
fatal error that can't be handled by code, similar to an assert in
C? That seems

You are not talking C++ exceptions here, but a structured ones, which
as a somewhat different sort. If C++ exceptions would be spilling
into the logs, that would be really a nightmare.

C++ exceptions are implemented using structed exceptions when /EHa is
specified.