php函数内用try-catch可捕获exception类异常以避免脚本中断，但e_warning等错误需转异常才能捕获；应避免die/exit，明确区分异常（意外）与返回值（常态）语义。
php函数里用try-catch捕获错误但不中断整个脚本
PHP函数内出错，默认会冒泡到调用栈上层，甚至终止脚本。想让单个函数“自己扛住”错误、返回兜底值或日志而不崩全局，try-catch是唯一可靠手段——但必须注意错误类型是否能被捕获。
- 只有
Exception和继承自它的异常（如RuntimeException）能被catch捕获；E_WARNING、E_NOTICE这类错误默认不能 - 若函数里调用了可能触发警告的函数（比如
fopen()打开失败），需先用set_error_handler()把错误转成异常，或改用@抑制后手动判断返回值 -
catch块里别空着，至少记录$e->getMessage()或返回明确的失败信号（如null、false）
示例：
function safeJsonDecode($json) {
try {
$data = json_decode($json, true);
if (json_last_error() !== JSON_ERROR_NONE) {
throw new InvalidArgumentException('Invalid JSON: ' . json_last_error_msg());
}
return $data;
} catch (Exception $e) {
error_log('JSON decode failed: ' . $e->getMessage());
return null;
}
}
php函数内触发错误却不让调用方崩溃
有时你希望函数主动报错（比如参数非法），但又不想让上层未加 try 的代码直接 fatal。关键不是“抛不抛”，而是“抛什么”。
- 用
throw new InvalidArgumentException()等标准异常类，比trigger_error()更可控——后者只能靠自定义错误处理器拦截，且无法被catch捕获 - 避免在函数里用
die()或exit()，它们会无条件终止整个请求，和“局部处理”目标完全相反 - 如果函数是供他人调用的工具函数，文档里要写清哪些异常可能被抛出，否则调用方根本不知道该不该
try
error\_reporting和display\_errors对函数内错误处理的影响
这两个配置不改变错误能否被 try-catch 捕获，但会影响错误是否显示或记录，进而掩盖真实问题。
动态WEB网站中的PHP和MySQL：直观的QuickPro指南第2版
下载
动态WEB网站中的PHP和MySQL详细反映实际程序的需求，仔细地探讨外部数据的验证(例如信用卡卡号的格式)、用户登录以及如何使用模板建立网页的标准外观。动态WEB网站中的PHP和MySQL的内容不仅仅是这些。书中还提到如何串联JavaScript与PHP让用户操作时更快、更方便。还有正确处理用户输入错误的方法，让网站看起来更专业。另外还引入大量来自PEAR外挂函数库的强大功能，对常用的、强大的包
-
error_reporting(E_ALL & ~E_NOTICE)会让Notice消失，但不会让它变成异常——所以try-catch依然抓不到 -
display_errors=On时，未捕获的异常会直接输出堆栈到页面，暴露敏感路径；线上环境必须关掉，靠日志排查 - 函数内用
error_log()记录异常时，确保log_errors=On且error_log指向有效文件，否则日志就丢了
函数返回false/null/throw三者怎么选
这不是风格问题，而是接口契约问题：调用方得清楚“失败”意味着什么。
立即学习“PHP免费学习笔记（深入）”；
- 操作本身可能失败但属于正常流程（如查数据库没找到记录），返回
null或空数组更自然 - 输入明显非法（如传了非字符串给需要字符串的参数），应该
throw异常，强迫调用方处理，而不是静默返回false - 用
false要特别小心——PHP里0、""、[]都是 falsy，容易和真实业务结果混淆；真要用，务必配合严格比较=== false
真正难的不是语法，是每次写函数前想清楚：这个错误，是“意外”还是“常态”？前者该抛异常，后者该设计成可预期的返回值。
