uncaught C++ exceptions left unreported in MSYS terminal

[jdtournier]

Description / Steps to reproduce the issue

I've noticed that C++ exceptions left uncaught are not reported by the MSYS Shell terminal or handled in any way, with the command exiting with a zero exit code. This behaviour is not seen with the MinGW64 or UCRT64 Shells: in both cases, the exception is handled by the default exception handler, reported on the terminal, and the command exits with a non-zero exit code.

My apologies if this is a known limitation. I've search the issue tracker, but couldn't find any information about this specific issue (though I've come across lots of issues about exceptions in general...).

My test case:

---

test_exceptions.cpp:

#include <stdexcept>

int main ()
{
  throw std::runtime_error("error");
  return 0;
}

---

Compiled under MSYS Shell using g++:

$ g++ test_exceptions.cpp -o test_exceptions

---

In case anyone is wondering: this is not a showstopper, I can easily catch the exception in my own try/catch clause (and that works as expected), as I would in any serious project. But I'm hoping to use the MSYS Shell for my Intro to C++ course, and it would be preferable if the student's very first use of the throw statement wasn't silently ignored...

Expected behavior

When compiling and running in either MinGW64 or UCRT64 Shell, things work as expected: the uncaught exception is reported by the default handler, and the command exits with a non-zero exit code. This is the behaviour I was expecting:

$ ./test_exceptions.exe
terminate called after throwing an instance of 'std::runtime_error'
  what():  error
$ echo $?
127

Actual behavior

When running in MSYS Shell, the uncaught exception is left unreported, and the program exits with a zero exit code:

$ ./test_exceptions.exe
$ echo $?
0

Also worth noting:

• If the program is compiled using the MSYS version of g++, but run in the UCRT64 Shell, the problem behaviour persists.
• If the program is compiled using the UCRT64 version of g++, but run in the MSYS Shell, the problem behaviour also persists.

Verification

• I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MSYS_NT-10.0-22631

Are you willing to submit a PR?

No response