9

I've got several long running boost threads that I want to be able to shut down by interrupting them. All of the documentation I can find says that you can catch the thread_interrupted exception, but it doesn't really say what happens if you don't. I would assume it kills the thread (and hopefully the thread gets properly cleaned up). But then does the exception die off with the thread? Or does it get passed up to the main thread and kill it too?

Rob W.
  • 362
  • 5
  • 18

1 Answers1

10

The exception is just like any other C++ exception. If you choose not to catch it, it will cause the same effect as any other unhandled exception.

If left uncaught, it will not propagate to the main thread, but could cause other undesirable behaviour. On Visual C++, by default this will terminate your process, for example.

In general, defensive programming practice would dictate that you should catch any exception your code can throw - just the same as you would check for error from an OS API that you called.

There's a backgrounder on interruption here by the person who wrote a lot of the Boost.Thread code.

Steve Townsend
  • 53,498
  • 9
  • 91
  • 140
  • Hm. I certainly didn't realise that letting the exception bubble up can terminate the entire process in some environments (it's not the case in ours). Thanks – Lightness Races in Orbit Jun 16 '11 at 16:26
  • @Tomalak - I suppose this depends 100% on the compiler. – Steve Townsend Jun 16 '11 at 16:29
  • A coworker of mine threw together a test, which shows that interrupting a thread, and not handling the exception, does not terminate the process. This was confirmed via both GCC on a Linux box, and VC++ on a Windows box. I've read the document you linked, but that doesn't really specify what happens after the thread is ended and cleaned up. – Rob W. Jun 16 '11 at 16:46
  • @Rob - agreed about the lack of detail on behaviour in this case. My view is that if it can be thrown, it should be handled. That way you are not relying on best guess, you are in control of your thread's destiny and can close it down clean on each target platform upon interruption. Interesting that your test info that seems to contradict the VC++ docs. All the more reason to not rely on behaviour for unhandled exceptions? – Steve Townsend Jun 16 '11 at 16:53
  • I completely agree. I'm surprised that an environment would ever terminate the entire process in this scenario, but there's more than enough ambiguity here to stay well clear of the possibility altogether. @RobW: Two tests are not conclusive for general behaviour. – Lightness Races in Orbit Jun 16 '11 at 17:08
  • There is a whole philosophy school that advocates the cons of defensive programming. Care should be taken. C.f: http://danielroop.com/blog/2009/10/15/why-defensive-programming-is-rubbish/ – v.oddou Feb 21 '13 at 09:29
  • This is not about defensive programming. It is about library design. When using `boost::thread` you have a guarantee that `thread_interrupted` will be caught by **it**. Which is (a) why you don't need to catch it (b) why the whole program isn't terminated. In fact, for purity in "defensive programming" here, if you did catch the exception, you should probably rethrow it so the library gets the intended clues. (I'm pretty sure though that the library has undocumented internal ways to detect an interruption request in progress, so it is mostly purist) – sehe Mar 16 '22 at 13:07