本文介绍如何通过自定义异常类与全局异常处理器，替代重复创建 response 对象的手动错误响应逻辑，提升 php rest api 的可维护性、一致性和专业性。
本文介绍如何通过自定义异常类与全局异常处理器，替代重复创建 response 对象的手动错误响应逻辑，提升 php rest api 的可维护性、一致性和专业性。
在构建 RESTful API 时，频繁手动实例化 Response 对象并逐行设置状态码、消息和成功标志（如 $response->setHttpStatusCode(400)），不仅代码冗余、易出错，还严重违反 DRY（Don’t Repeat Yourself）原则和单一职责原则。更专业的做法是——将错误语义交由异常表达，将响应逻辑交由统一处理器完成。
✅ 推荐方案：基于异常的声明式错误处理
1. 定义语义化异常类
为 HTTP 错误建立清晰的继承体系，便于分类处理：
// src/Exception/HttpException.php
class HttpException extends RuntimeException
{
protected int $statusCode;
public function __construct(string $message, int $statusCode = 500, ?Throwable $previous = null)
{
parent::__construct($message, $statusCode, $previous);
$this->statusCode = $statusCode;
}
public function getStatusCode(): int
{
return $this->statusCode;
}
}
你还可以进一步细化（可选）：
class BadRequestException extends HttpException
{
public function __construct(string $message = 'Bad Request') {
parent::__construct($message, 400);
}
}
class NotFoundException extends HttpException
{
public function __construct(string $message = 'Not Found') {
parent::__construct($message, 404);
}
}
2. 重构业务逻辑：用 throw 替代 new Response()
原代码中大量重复的响应构造，现简化为语义明确的异常抛出：
if (!array_key_exists('newsid', $_GET)) {
throw new BadRequestException('Haber id\'si eksik.');
}
$news_id = $_GET['newsid'];
if ($news_id === '' || !is_numeric($news_id)) {
throw new BadRequestException('Haber id\'si boş olamaz veya sayı olmalı!');
}
if ($_SERVER['REQUEST_METHOD'] === 'GET') {
try {
$stmt = $readDB->prepare("SELECT id,title,details,poster_link FROM tb_news WHERE id = :id");
$stmt->bindParam(':id', $news_id, PDO::PARAM_INT);
$stmt->execute();
if ($stmt->rowCount() === 0) {
throw new NotFoundException('Haber Bulunamadı');
}
$news = $stmt->fetch(PDO::FETCH_ASSOC);
// 成功响应（仍使用 Response 类，但仅用于成功路径）
$response = new Response();
$response->setHttpStatusCode(200);
$response->setSuccess(true);
$response->setData($news);
$response->send();
exit;
} catch (PDOException $e) {
// 数据库异常无需暴露细节，统一转为 500
throw new HttpException('Sunucu hatası', 500);
}
}
✅ 优势：逻辑聚焦于业务本身；错误条件即刻中断流程；无重复对象创建；异常携带完整上下文（消息 + 状态码 + 可选堆栈）。
3. 全局异常处理器：一次注册，处处生效
在入口文件（如 index.php 或框架启动处）注册统一处理器：
// 设置全局异常处理器
set_exception_handler(function (Throwable $e): void {
$response = new Response();
if ($e instanceof HttpException) {
$response->setHttpStatusCode($e->getStatusCode());
$response->setSuccess(false);
$response->addMessage($e->getMessage());
} else {
// 非预期异常（如语法错误、内存溢出）——记录日志，返回通用错误
error_log('[FATAL] Unhandled exception: ' . $e->__toString());
$response->setHttpStatusCode(500);
$response->setSuccess(false);
$response->addMessage('Sunucu hatası');
}
$response->send();
exit;
});
⚠️ 注意事项：
- 绝不向客户端暴露敏感信息：数据库连接失败、SQL 语句、文件路径等必须屏蔽，仅返回用户友好的泛化提示；
-
PDO 默认不抛异常：请确保已启用
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，否则PDOException不会触发； -
避免在
catch中重复exit或send()：统一由异常处理器接管，保证出口唯一； -
开发环境可扩展：配合
debug_backtrace()或 Monolog 记录详细上下文，生产环境严格关闭调试输出。
✅ 总结
用 throw new HttpException(...) 替代 new Response()->setXxx()->send()，本质是将“错误是什么”（What）与“如何响应”（How）解耦。前者由业务层声明，后者由基础设施层统一实现。这种分层设计显著提升代码可读性、可测试性与可演进性——当你未来需要支持 JSON:API 标准、添加错误追踪 ID 或集成 Sentry 时，只需修改异常处理器，而无需遍历所有 if 分支。
真正的工程效率，不在于写得快，而在于改得稳、看得清、靠得住。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
