title: RAII classes with transient resources
body: <p>I'm fairly new to many modern C++/OOP concepts and I've got a question about RAII design.</p>
  
  <p>Consider a class that manages and interfaces a transient resource: A TCP socket connection, a connection to a Bluetooth device, and communication with said devices. Things like this. We can assume the class is completely useless if the resource is or becomes unavailable.</p>
  
  <p>I can't decide if RAII (specifically, acquiring/connecting to the resource in the ctor) is good or bad for this type of class.</p>
  
  <p>On the one hand, if the class functionality depends on the resource, it seems to make sense to throw from the ctor rather than on some later Connect() call. On the other hand, acquiring a transient resource typically involves some blocking and/or async operation, which feels like poor constructor design to me.</p>
  
  <p>I've found a few other topics that dance around this question, but haven't fully satisfied my curiosity:
  <a href="https://stackoverflow.com/questions/42281711/raii-berkeley-sockets-and-stl-containers">RAII, Berkeley Sockets, and STL Containers</a></p>
  
  <p><a href="https://stackoverflow.com/questions/28922341/raii-for-resources-that-can-be-invalidated">RAII for resources that can be invalidated</a></p>
  
  <p>Any guidance on best-practices will be appreciated!</p>
  
  <p>EDIT: Clarifying my question based on comments below. With the portion of RAII that deals with constructors establishing all class invariants -- a device connection is an invariant because the class should guarantee all public methods that try to communicate with that device are valid after construction. HOWEVER -- can this actually be considered a class invariant since the program has no control over the remote device's availability?</p>