viewer.git/indra/llcommon/llexception.h, branch main

Revert "Promote seh_catcher() et al. to llexception.{h,cpp} for general use."

2025-06-03T08:21:58Z

This reverts commit 71d777ea126e7f02cb46c11bdb606094ca06f75c.

Revert "Fix up llexception.h's cross-platform SEH wrapper."

2025-06-03T08:20:27Z

This reverts commit 5ed8df22cd59680a685c4ada7daa5555bf59d4fe.

Fix up llexception.h's cross-platform SEH wrapper.

2024-05-28T17:22:05Z

Introduce AlwaysReturn specialization, which always discards any result of calling the specified callable with specified args. Derive new Windows_SEH_exception from LLException, not std::runtime_error. Put the various SEH functions in LL::seh nested namespace, e.g. LL::seh::catcher() as the primary API. Break out more levels of Windows SEH handler to work around the restrictions on functions containing __try/__except. The triadic catcher() overload now does little save declare a std::string stacktrace before forwarding the call to catcher_inner(), passing a reference to stacktrace along with the trycode, filter and handler functions. catcher_inner() accepts the stacktrace and the three function template arguments. It contains the __try/__except logic. It calls a new filter_() wrapper template, which calls fill_stacktrace() before forwarding the call to the caller's filter function. fill_stacktrace(), in the .cpp file, contains the logic to populate the stacktrace string -- unless the Structured Exception is stack overflow, in which case it puts an explanatory string instead. catcher_inner()'s __except clause passes not only the code, but also the stacktrace string, to the caller's handler function. It wraps the caller's handler function in always_return(), where rtype is the type returned by the trycode function. This allows a handler to return a value, while also supporting the void handler case, e.g. one that throws a C++ exception. (This is why we need AlwaysReturn: some trycode() functions are themselves void.) For the dyadic catcher() overload, introduce common_filter() containing the logic to distinguish a C++ exception from any other kind of Structured Exception. The fact that the stacktrace is captured before the filter function is called should permit capturing a stacktrace for a C++ exception as well as for most other Structured Exceptions. As before, the monadic catcher() overload supplies the rethrow() handler, in the .cpp file. Change existing calls from seh_catcher() to LL::seh::catcher().

Promote seh_catcher() et al. to llexception.{h,cpp} for general use.

2024-05-24T21:34:04Z

#824 Process source files in bulk: replace tabs with spaces, convert CRLF to LF, and trim trailing whitespaces as needed

2024-04-29T04:56:09Z

SL-14347 Crash at ChoosePixelFormat SEH

2020-12-01T16:22:24Z

DRTVWR-476: Enrich LLExceptions thrown by LLTHROW() with stack trace.

2020-03-25T23:21:16Z

The LLTHROW() abstraction allows us to enrich the subject exception with a boost::stacktrace -- without having to propagate the boost/stacktrace.hpp header throughout the code base. To my delight, our existing use of boost::current_exception_diagnostic_information() already reports the newly added boost::stacktrace information -- we don't have to query it specifically!

MAINT-5011: Catch unhandled exceptions in LLCoros coroutines.

2016-08-18T21:33:44Z

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.

MAINT-5011: Use BOOST_CURRENT_FUNCTION instead of __PRETTY_FUNCTION__

2016-08-18T15:06:51Z

since Visual Studio doesn't know __PRETTY_FUNCTION__, and Boost already has a portable macro to Do The Right Thing.

MAINT-5011: Try to enrich catch (...) logging throughout viewer.

2016-08-17T19:40:03Z

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.