C++构造函数体内处理异常是否属于不良编程实践？

首先明确两个不同的“处理异常”场景，合理性完全不同：

• 在构造函数内部吞掉错误、不对外通知失败：属于严重的不良实践。这种情况会生成状态非法的悬空对象，调用者后续调用对象方法时必然触发未定义行为，完全不可取。
• 在构造函数检测到socket()、bind()等调用失败时，直接抛出异常终止实例化流程：是完全符合C++ RAII设计规范的标准做法，合理性很高。

合理性说明 #

C++构造函数没有返回值，无法通过返回值向调用者传递初始化失败的状态，抛出异常是语言设计层面唯一的标准化错误通知方式。
你的设计预期是「传入端口实例化对象后，直接可以用于和客户端建立连接」，这完全匹配RAII“资源获取即初始化”的核心思想：构造完成等价于资源（监听端口）申请完成，不需要调用者额外执行初始化步骤，也避免了调用者漏调用初始化方法的问题。

潜在问题与规避方案 #

采用这种方案时，需要注意几个容易踩的坑：

1. 做好半初始化状态的资源清理
   构造函数执行过程中抛异常时，已经完成构造的成员变量会自动调用析构函数，但你手动申请的系统资源需要自行清理。比如你已经调用socket()成功拿到文件描述符，后续bind()调用失败抛异常前，必须手动关闭已经拿到的文件描述符，避免资源泄漏。更稳妥的方案是用RAII包装类托管所有系统资源，出作用域自动释放。
2. 不要将accept()放到构造函数中执行
   accept()是阻塞调用，放到构造函数中会导致实例化过程直接卡住，直到有客户端连接才会返回，完全不符合你设计的预期，建议将accept()作为独立的成员方法暴露给调用者。
3. 明确异常依赖
   调用者实例化你的TCP服务器类时，必须用try/catch包裹实例化逻辑，或者在上层统一处理异常，否则初始化失败会直接触发程序终止，这一点要在类的使用说明中明确标注。

替代方案 #

如果你的项目规范禁止使用异常，可以采用两阶段初始化方案：构造函数仅完成基础成员变量初始化，额外暴露bool start(uint16_t port)方法，在该方法中执行socket()、bind()、listen()流程，用返回值标识初始化是否成功，同步提供get_error()方法返回具体错误码。这种方案的缺点是需要调用者主动检查返回值，存在漏检查导致拿到非法对象的风险。

内容的提问来源于stack exchange，提问作者thbake