Q: How to elegantly handle exception-throwing constructors? I sometimes wonder how to handle construction of objects which can throw in their constructor. I wonder how you do it.
Consider the following snippet. I have a class, named TCPMessage, which represents a message my "server" receives over TCP. If the received message is invalid (i.e. the CRC32 calculated in the TCPMessage's constructor doesn't check out), TCPMessage's constructor throws.
So below is how I do it. Do you know of any better way? I'm asking, because it doesn't really look too elegant.
void TCPConnection::handleRead(
  const boost::system::error_code& error,
  char* read_buffer
)
{
  if (!error) {
    TCPMessage* message = NULL; // being verbose here
    try {
      message = new TCPMessage(read_buffer);
    } catch (const char* e) {
      std::cerr << "Instatiating TCPMessage: " << e << std::endl;
    } catch (...) {
      std::cerr << "Instatiating TCPMessage: unknown exception." << std::endl;
    }

    if (message) {
      // if created succesfully
      // process the message and delete it
      SeekurJrRC::Core::Driver& driver = boost::asio::use_service<SeekurJrRC::Core::Driver>(_io_service);
      driver.processMessage(*message);
      delete message;
    }
  }
  delete [] read_buffer;
}

Oh yeah, an I know about knowing better than to use char* read_buffer and deleting it in another function. shared_ptr's the way, I know.

A: Your problem isn't exceptions, it's raw pointers and lack of RAII.
Sanitizing your code a bit:
void TCPConnection::handleRead(
  const boost::system::error_code& error,
  char* read_buffer
)
{
  if (!error) {
    try {
      TCPMessage message(read_buffer);
      SeekurJrRC::Core::Driver& driver = boost::asio::use_service<SeekurJrRC::Core::Driver>(_io_service);
      driver.processMessage(message);

    } catch (const char* e) {
      std::cerr << "Instatiating TCPMessage: " << e << std::endl;
    } catch (...) {
      std::cerr << "Instatiating TCPMessage: unknown exception." << std::endl;
    }
  }
}

new calls should be wrapped in RAII objects, not dangle around freely in your user code. delete calls should never be explicit, but instead be handled by the destructors defined in your RAII objects.
Then your objects will automatically get destroyed and clean up after themselves if an exception is thrown, and you don't need your over-complicated "try/catch/check-for-success" dance. If an exception was not thrown, you continue normally. If it was thrown, you leave the try block, and your objects are destroyed automatically.
Note that here you don't actually need the try/catch block any more. The only thing you use the  catch for is to print an error message. It's not necessary for the program flow or to prevent resource leaks. Normally you would handle the error where you can meaningfully do so. Presumably that's somewhat higher up the call tree, where you know what to do about a failed read. At this level, it makes more sense to just let the exception escape to indicate that an error occurred.
void TCPConnection::handleRead(
  const boost::system::error_code& error,
  char* read_buffer
)
{
  if (!error) {
    TCPMessage message(read_buffer);
    SeekurJrRC::Core::Driver& driver = boost::asio::use_service<SeekurJrRC::Core::Driver>(_io_service);
    driver.processMessage(message);
  }
}


A: Somewhere you have to handle the exception. If you don't want to clutter your code everytime where you do new TCPMessage(read_buffer) then you can use special syntax for constructor to handle exception only at one place. e.g.
class TCPMessage {
...
public:
  TCPMessage (const char *read_buffer)
  try {
    ...
  }
  catch(const char *p){ ... }
  catch(...) { ... }
...
};


A: What is wrong with enclosing the processing in the try-catch-block?
void TCPConnection::handleRead(
  const boost::system::error_code& error,
  char* read_buffer
)
{
  if (!error) {
     try {
         std::auto_ptr<TCPMessage> message(new TCPMessage(read_buffer));

         // if created succesfully
         // process the message and delete it
         SeekurJrRC::Core::Driver& driver = boost::asio::use_service<SeekurJrRC::Core::Driver>(_io_service);
         driver.processMessage(*message);
     } catch (const char* e) {
         std::cerr << "Instatiating TCPMessage: " << e << std::endl;
     } catch (...) {
         std::cerr << "Instatiating TCPMessage: unknown exception." << std::endl;
     }
  }
  delete [] read_buffer;
}

Of course, you should use suitable smart pointers for exception safety, when another part of the code can throw. It might also be good to not handle all exceptions right in this function.

A: Usual way is to handle exceptions at the point where you can resolve them.
For example, if the "connection was dropped" exception is thrown, you can handle it somewhere where you can ask the user what to do about it : either reconnect, or maybe close the application.
You do not necessarily need to handle the exception in that function. I see you are only printing the error message. If that's the only thing to do, then it is ok. As you said, it would be better to use smart pointers. Something like this :  
void TCPConnection::handleRead(
  const boost::system::error_code& error,
  char* read_buffer
)
{
  if (!error) {
    try{
    std::auto_ptr< TCPMessage > message( new TCPMessage(read_buffer) );
    SeekurJrRC::Core::Driver& driver = boost::asio::use_service<SeekurJrRC::Core::Driver(_io_service);
    driver.processMessage(message.release());

    } catch (const SomeException e) {
      std::cerr << "Instatiating TCPMessage: " << e << std::endl;
    } catch (...) {
      std::cerr << "Instatiating TCPMessage: unknown exception." << std::endl;
    }

  }
  delete [] read_buffer;
}

Take a note that it is better to catch some custom exception type, instead of const char*.

A: Constructors should only take care of resource allocation related jobs. if we need to have complex initialization before we use it, we need a dedicated init member function. That's how ATL does. This way we could avoid throwing exceptions in constructors. 
Smart pointers do not solve the problem, we might have memory leaks when an exception is thrown in the constructor. 
    std::autor_ptr<Widget> pWidget(new Widget()); 

The above statement will do three things at least:
   1. call new operator to allocate memory
   2. construnct an object by calling its constructor 
   3. constuct the smart poniter. 

If an exception is throw in the second step, the smart pointer is not constructed, it's never be destoryed. As a result, we leak the memory allocated in the first step. 
