Logging C++ exceptions inside try/catch block

[maxp1256]

Hello,

I'm trying to log an exception from a catch block in our C++ app with sentry native 0.6.6

Currenty the catch block is declared with

catch(...) {
  /* set bad return code */
}

According to docs/AI i've changed it to:

catch (std::exception& ex) { 
  GetApp()->LogException("std::exception", ex.what(), NULL); 
  /* set bad return code */ 
}

and log the exceptions with:

void LogException(const char* szExceptionType, const char* szExceptionValue, const char* szEventMessage)
{
  auto event = sentry_value_new_message_event(SENTRY_LEVEL_FATAL, nullptr, szEventMessage);
  auto exception = sentry_value_new_exception(szExceptionType, szExceptionValue);
  sentry_event_add_exception(event, exception);
  sentry_value_set_stacktrace(exception, nullptr, 0);

  const auto uuid = sentry_capture_event(event);
}

Basically it's working, but I'm not sure if I'm collecting all types of exceptions?

for instance the following is not captured as std::execption and falls through the default catch (...) handler:

*((unsigned int*)0) = 0xDEAD01;

[supervacuus]

Basically it's working, but I'm not sure if I'm collecting all types of exceptions?

In short: no.

1. Also related to your other question: a C++ catch will only receive C++ exceptions, not all SEH exceptions. If you want to handle SEH exceptions, which includes hard faults like memory access errors and C++ exceptions, you need to use the SEH primitives.
2. You will only catch exceptions in the type hierarchy of std::exception, thus guaranteeing a what() interface. In C++, you can throw almost anything (besides incomplete or abstract types), so even if you only consider catching C++ exceptions, you will ignore all that aren't a std::exception.

for instance the following is not captured as std::execption and falls through the default catch (...) handler:

Yes, a NULL-pointer dereference does not result in a C++ exception, and such a catch will be bypassed. While C++ exceptions are implemented in terms of SEH exceptions on Windows, SEH exceptions are a superset. If you want to handle all SEH exceptions, use the SEH primitives (__try, __except, __finally). However, these are at a much lower level (you'd have to manually filter the incoming SEH exception to identify it as a C++ exception) and have different semantics. Of course, these handlers are not portable to other platforms.

[maxp1256]

Thanks @supervacuus

Currently I've managed to install a custom SEH exception helper class with _set_se_translator and catch those exceptions. For std::exceptions I need to add another catch for std::exception. But this is done with a macro at a single place.

Another problem is that I'm unable to get the callstack to sentry. I'm logging the exception in the catch with

  auto event = sentry_value_new_message_event(SENTRY_LEVEL_FATAL, nullptr, szEventMessage);
  auto exception = sentry_value_new_exception(szExceptionType, szExceptionValue);
  sentry_event_add_exception(event, exception);
  sentry_value_set_stacktrace(exception, nullptr, 0);

  const auto uuid = sentry_capture_event(event);

The error in sentry is:
Sentry has identified the following problems for you to fix
A required debug information file was missing (3)
OurApp.exe
Ourdll.dll
sentry.dll
Unable to fetch HTTP resource (1)
ntdll.dll

The raw stack trace is very minimal, there are no file versions or path included, just the plain file names with a hex digit. Do I need to call anything more? Add a minidump?

[supervacuus]

You must upload debug information for the executables and DLLs listed (binary + pdb) so that the processing in the backend can symbolicate the trace: https://docs.sentry.io/cli/dif/

You can also enable sentry_options_set_symbolize_stacktraces() so that the SDK will try to retrieve the symbols before sending the event.

[maxp1256]

Hello @supervacuus
We normally do not upload our symbols to sentry but we've configured a link to your symbol server. While debugging I've relealized that this is a per-project-setting which was not configured for the new project. Sorry!