10

I have this method in library:

#include <stdexcept>

mytype* myfunc()
{
  throw std::runtime_error("is uncatchable");
}

and this in int main() of executable process which links library.

  try {  myfunc(); }
  catch(std::exception const& ex) { std::cout << "handled: " << ex.what() << std::endl;  }
  catch(...) {   std::cout << "something else..." << std::endl;  }

And that is the output:

terminate called after throwing an instance of 'std::runtime_error'
  what(): is uncatchable
Abort (core dumped)

Question: Why exception was not catch?

I'm not managing my compiler's flags (icc-11.X), also OS is also not under my control.

List of compiler flags:

-DLINUX -DLINUX_X64 -DGNU_SOURCE -fPIC -Wcheck -Wshadow -Wdeprecated -Wreturn-type -Wcomment -Wmissing-prototypes -Wp64 -Drcsid="__attribute__((used)) rcsid" 
-D__EXTENSIONS__ -D__STD_C__ -D_XOPEN_SOURCE=500 -D_GNU_SOURCE -DNDEBUG

__EXCEPTIONS is defined.

May there exist settings for Linux which lead to this?

May there exist settings for compiler which lead to this?

Arkady
  • 2,084
  • 3
  • 27
  • 48
  • Works [fine here](https://ideone.com/ilCpnS) – Killzone Kid May 14 '18 at 11:21
  • FWIW GCC and Clang work perfectly fine - might be an ICC bug? – hlt May 14 '18 at 11:21
  • Definitely it should work fine in usual case. I think it may be related to some OS settings or to some specific compiler settings, if such exist. – Arkady May 14 '18 at 11:22
  • Can you determine and edit into the question the list of compiler flags being used? (It looks like icc does have an `-fno-exceptions`.) – aschepler May 14 '18 at 11:26
  • 3
    IMO problem is how library is linked with application (so issue can't be reproduced with online compilers). For some reason `STL` library is not shared between library and application and this may confuse RTTI. Please provide detailed information about build process. – Marek R May 14 '18 at 11:29
  • It looks like people have run into [similar problems](https://software.intel.com/en-us/forums/intel-c-compiler/topic/310404) with icc before. – Sean Cline May 14 '18 at 11:29
  • I've added compiler flags. Also I've done test: if I `throw "uncatchable exception"` from library, it still can't be catch by `catch(...)`. So I think this experiment is not in sharing `STL` – Arkady May 14 '18 at 12:31
  • @Arkady throw "uncatchable exception" will throw a const char* - which isn't stl. – UKMonkey May 14 '18 at 12:55
  • 1
    Is __EXCEPTIONS defined when you compile? https://software.intel.com/sites/default/files/m/d/4/1/d/8/icc.txt states that -fnoexceptions will have that undefined; because maybe there's some config file that it's picking up that flag from? – UKMonkey May 14 '18 at 13:00
  • @UKMonkey, exactly. So, if with `const char*` it will not work, then problem is not in `STL` – Arkady May 14 '18 at 13:45
  • @UKMonkey great research, thank you. Will check noW – Arkady May 14 '18 at 13:48
  • `__EXCEPTIONS` is defined. – Arkady May 14 '18 at 13:55
  • It looks like problem was similar to this: https://stackoverflow.com/questions/38878999/try-catch-doesnt-work-in-shared-library – Arkady May 21 '18 at 07:56
  • I didn't check if problem left if I will replace ld with compiler, because it's hard to do it quickly with our environment, but I'm pretty sure it was the reason. – Arkady May 21 '18 at 07:57
  • Are there any functions/methods on the call stack that are marked `noexcept`? – Martin York Dec 27 '22 at 08:07

0 Answers0