LLError::abbreviateFile() is specifically to avoid cluttering log output with
the prefix of an absolute file path on the original build system, pointless
for anyone trying to read the log.
In some places we want to log the same information but with different severity
depending on specifics. In other cases we need to test the availability of the
logging subsystem before engaging it. LL_VLOGS() accepts an LLError::ELevel
argument that can differ with each call, while retaining the desirable feature
of deciding only once for each level.
This particular test relied on there being exactly one instance of the string
"indra" in the source file's __FILE__ path -- which is usually true, but not
if the developer clones the viewer source repo under a parent directory whose
path itself contains "indra". Fix to handle any number of occurrences.
This means that an exception derived from LLContinueError thrown in an
LLEventPump listener won't prevent other listeners on the same LLEventPump
from receiving that event.
LLView::childFromPoint(), which is declared to return LLView*, contained a
code path that could 'return false'. This is blatantly wrong. Why has it
compiled on our other compilers so far?
Wrap coroutine call in try/catch in top-level coroutine wrapper function
LLCoros::toplevel(). Distinguish exception classes derived from
LLContinueError (log and continue) from all others (crash with LL_ERRS).
Enhance CRASH_ON_UNHANDLED_EXCEPTIONS() and LOG_UNHANDLED_EXCEPTIONS() macros
to accept a context string to supplement the log message. This lets us replace
many places that called boost::current_exception_diagnostic_information() with
LOG_UNHANDLED_EXCEPTIONS() instead, since the explicit calls were mostly to
log supplemental information.
Provide supplemental information (coroutine name, function parameters) for
some of the previous LOG_UNHANDLED_EXCEPTIONS() calls. This information
duplicates LL_DEBUGS() information at the top of these functions, but in a
typical log file we wouldn't see the LL_DEBUGS() message.
Eliminate a few catch (std::exception e) clauses: the information we get from
boost::current_exception_diagnostic_information() in a catch (...) clause
makes it unnecessary to distinguish.
In a few cases, add a final 'throw;' to a catch (...) clause: having logged
the local context info, propagate the exception to be caught by higher-level
try/catch.
In a couple places, couldn't resist reconciling indentation within a
particular function: tabs where the rest of the function uses tabs, spaces
where the rest of the function uses spaces.
In LLLogin::Impl::loginCoro(), eliminate some confusing comments about an
array of rewritten URIs that date back to a long-deleted implementation.
KDU internally throws kdu_exception, which is a typedef for int. It's possible
that such an exception might leak out.
Our usual strategy for unknown exceptions is to catch (...) and let
boost::current_exception_diagnostic_information() handle them. However, for
int (or a class not derived from std::exception), that function will only
shrug and report no information available.
Besides, we want to format kdu_exception specially anyway. First, the KDU
#defines are in hex, so we should report the value in hex. But on inspection,
certain of those hex values are actually multibyte ASCII literals in disguise
-- so also report the byte string value.
Turns out we have a surprising number of catch (...) clauses in the viewer
code base. If all we currently do is
LL_ERRS() << "unknown exception" << LL_ENDL;
then call CRASH_ON_UNHANDLED_EXCEPTION() instead. If what we do is
LL_WARNS() << "unknown exception" << LL_ENDL;
then call LOG_UNHANDLED_EXCEPTION() instead.
Since many places need LOG_UNHANDLED_EXCEPTION() and nobody catches
LLContinueError yet, eliminate LLContinueError& parameter from
LOG_UNHANDLED_EXCEPTION(). This permits us to use the same log message as
CRASH_ON_UNHANDLED_EXCEPTION(), just with a different severity level.
Where a catch (...) clause actually provides contextual information, or makes
an error string, add boost::current_exception_diagnostic_information() to try
to figure out actual exception class and message.
callum@lindenlab.com