set_unexpected() Didn't work

[nickman]

Hi

I was seeing the behavior of unexpected() function in exception handling.

I was wondering why the function set for un_expected() didn't called when exception was thrown.

Below is the code:

#include <iostream>       
#include <exception>     

void myunexpected () {
  std::cerr << "unexpected called\n";
  throw 0;     /
}

void myfunction () throw (int) {
  throw 'x';   
}

int main (void) {
  std::set_unexpected (myunexpected);
  try {
    myfunction();
  }
  catch (int) { std::cerr << "caught int\n"; }
  return 0;
}

I was expecting the set_unexpected() should call myunexpected() and throw an int exception for the handler is there.

I put debugger, but myunexpected() was not called.

Is something wrong with code implementation or it is run time behavior of set_unexpected() function?

If it is so, then what's the use of set_unexpected() ?

Thanks

[grumpy]

One explanation is that the slash on the end of your line 6 would prevent the code compiling. Some IDEs, if you select "Run", will run an older version (previously compiled) of the executable in such circumstances.

Even if your code does compile/link, debuggers don't always step into, or even permit stepping into, functions called during stack unwinding once an exception has been thrown. Once consequence of that is, when stepping with a debugger, it will not step into your myunexpected() function.

Try doing a Build/Clean and Rebuild and (if that succeeds) run your program to completion, and see what output you get.

[nickman]

Thanks..

It was copy/paste error.
I clean sol and rebuild it.. and the result was same.Program was terminated abnormally.

I didn't debug this time but the function myunexpected() was not called.

Thanks

[grumpy]

If you're using a Microsoft compiler, there's a fair chance it doesn't support exception specifications (i.e. it ignores them). That would explain the behaviour.

That's no longer considered a problem, as exception specifications were deprecated in the latest C++ standard (C++11). They were never particularly useful to begin with.,

[nickman]

Yes. I was using Visual Studio 2005.

So it means that exception specifications now not in standard C++ and we should not use them?

[grumpy]

Should is a strong word. Probably better to say their usage is discouraged.

Deprecated formally means identified in the standard as slated for removal from a future version of the standard. It is a fairly strong hint that the feature will go away.

Even if exception specifications remained standard, I would rarely (if ever) use them. And, if you stick with using VS2005, there's little point anyway.

[Elkvis]

Is it possible that this is happening because a char implicitly converts to an int?

[grumpy]

Is it possible that this is happening because a char implicitly converts to an int?

I doubt it. main() has a catch(int) clause, which would catch the exception in that case. The program would not then exit abnormally.