On Tue, Jul 14, 2009 at 7:49 PM, Alex Black<alex@alexblack.ca> wrote:

...

...

I'm using boost::asio for sockets, writing a response out to a client.

If the client stops part way through getting the response, then my server process dies:

terminate called after throwing an instance of

'boost::exception_detail::clone_impl<boost::exception_detail::error_in

...

fo_injector<boost::system::system_error>

...

' ? what():? Broken pipe

The code though is surrounded by try catch like this:

try { ??? ... } catch ( std::exception& e ) { ??? cout << e.what() << endl; } catch ( ... ) { ???? cout << "unexpected exception" << endl; }

How do I prevent my process from aborting/terminating like this? v

...

Have you verified that the code inside the try block executes on the same thread that the exception is occuring in?

Not explicitly, how would I do that?

thx

First put a breakpoint inside the try block. When it gets hit use whatever mechanism your debugger provides to see what thread you're in. In windows using MSVC, for example, you'd just add a watch for a variable called $TID which a special pseudo-variable that shows you the thread id. For other debuggers you'd have to consult the manual. Next register an unhandled exception handler. #include <exception> void unhandled_exception_handler() { std::cout << "Got an unhandled exception!" << std::endl; } int main(int argc, char** argv) { std::set_terminate(unhandled_exception_handler); //rest of your program. } Then put a breakpoint inside unhandled_exception_handler and when it gets hit walk up the callstack in the debugger to see where the exception is occuring. In addition you can determine the thread id again using the same method you used in the first step. My guess is that they're not in the same thread. I'm not sure if it applies to your scenario, but remember that the operation's completion handler is invoked on is not necessarily the same thread that the request is issued on depending on how you're using the io_service object. So while you have a try {} catch(...) {} in the completion handler, if the exception is on the other thread that does you no good.