对最近异常处理过程的总结

发布于 2020-02-04  38 次阅读


创意的实践是有代价的

代价就是Debug.

在弄完积分系统和排行榜系统之后,我又在网站首页(PC端)增加了视频播放的功能。

箭头位置暂停/继续 加号换视频 视频源: https://ak.hypergryph.com/index.html (明日方舟)

很好,现在能加的都加上了,就在PC端和移动端看下效果⑧

iPad
iPhoneX

看起来没有问题的说

但是一拿到实体机上各种奇葩的问题就出现了

来源:留言板

我拿手机看了一下,确实存在一大堆问题。原因不是没能适配Android,而是各种环境因素的干扰。

为此,我采取了另一种思维方式:对电脑端和移动端分别使用不同的主题,其中移动端的主题要能很好的适应各种环境。

很巧的是,WordPress是PHP语言编写的,并且内置了一个函数wp_is_mobile()

wordpress函数wp_is_mobile()是wordpress 3.4.0版本增加的一个内置函数,wp_is_mobile()函数的作用是检测当前浏览器是否运行在智能手机、平板电脑等移动设备上,返回一个布尔值。目前wp_is_mobile()函数支持Iphone、ipad、android、silk、kindle、BlackBerry、Opera Mini等众多移动设备及浏览器,使用该函数可以帮助开发者更好地制作响应式wordpress主题、独立手机主题或者各类型手机相关的插件。

wp_is_mobile() 函数的源代码

从源代码可以看出,其包含了几乎市面上所有的移动终端。BlackBerry也在其列。但不得不提的是,就在今天,TCL已经宣布不再销售黑莓品牌的手机。

近期,Blackberry Mobile Twitter帐户宣布了一则信息,从2020年8月31日起,TCL通信将不再销售黑莓品牌手机。

早在2016年12月,TCL宣布已获得创建和销售BlackBerry品牌智能手机的权利。之后并陆续推出了BlackBerry KEYone,Motion,KEY2和KEY2 LE等手机的发布。KEY手机极具特色,在全面屏时代采用物理键盘的BlackBerry黑莓设计。但面对竞争日益激烈的行业环境,BlackBerry近年的手机并未在市场中获得太多反响。可能也正是出于这样的原因,TCL现在决定将会于今年8月正式终止与BlackBerry的合作。

回到我们的话题。为了实现对不同平台间主题的切换,我写了一个小小的插件。但是就这几行代码就耗费了我很多时间。

目前还没有传到GayHub上,因为不清楚有没有人做过这个。并且更重要的是没做前台设置的界面,所以要开源还是要一段时间的修改与完善。

手机端主题的选择也耗费了我许多时间,并且奇怪的是,有些主题在电脑端和手机端都使用同一主题时,移动端的CSS还可以正常加载,但一旦将PC端主题换回 Sakura就又会出现蓝字白底(未能正常加载层叠样式表)的问题。

被PASS掉的插件或主题

最后,我选择了Personal22这个主题。正和 Sakura的二次元主题相反,他是极简风格的主题,对于移动端十分友好。并且已经投入使用。

前端的问题都解决了,但是后端总有一两个报错让人闹心。就譬如说这样:

本来好好的后台被这一行报错给毁了

但是我上文说过,WordPress是PHP语言编写的,所以我们可以将ini_set("display_errors",0);这行代码加入到wp-config文件中。这里简要做一些介绍:

引用自 https://www.php.net/manual/zh/function.error-reporting.php

error_reporting

(PHP 4, PHP 5, PHP 7)

error_reporting设置应该报告何种 PHP 错误

说明

error_reporting ([ int $level ] ) : int

error_reporting() 函数能够在运行时设置 error_reporting 指令。 PHP 有诸多错误级别,使用该函数可以设置在脚本运行时的级别。 如果没有设置可选参数 levelerror_reporting() 仅会返回当前的错误报告级别。

参数

level

新的 error_reporting 级别。 可以是一个位掩码也可以是一个已命名的常量。 强烈建议使用已命名的常量,以确保兼容将来的版本。 由于错误级别的添加、整数取值范围的增加, 较久的基于整数的错误级别不会总是和预期的表现一致。

可用的错误级别常量及其实际含义描述在了 predefined constants 中。

返回值

返回旧的 error_reporting 级别,或者在 level 参数未给出时返回当前的级别。

更新日志

版本 说明
5.4.0 E_STRICT 成为 E_ALL 的一部分
5.3.0 引入 E_DEPRECATEDE_USER_DEPRECATED
5.2.0 引入 E_RECOVERABLE_ERROR
5.0.0 引入 E_STRICT (但不包括在 E_ALL 之内)。

范例

Example #1 error_reporting() 范例

<?php

// 关闭所有PHP错误报告
error_reporting(0);

// Report simple running errors
error_reporting(E_ERROR E_WARNING E_PARSE);

// 报告 E_NOTICE也挺好 (报告未初始化的变量
// 或者捕获变量名的错误拼写)
error_reporting(E_ERROR E_WARNING E_PARSE E_NOTICE);

// 除了 E_NOTICE,报告其他所有错误
error_reporting(E_ALL E_NOTICE);

// 报告所有 PHP 错误 (参见 changelog)
error_reporting(E_ALL);

// 报告所有 PHP 错误
error_reporting(-1);

// 和 error_reporting(E_ALL); 一样
ini_set('error_reporting'E_ALL);

?>

注释

Warning

虽然 error_reporting 增强了 包含 E_STRICT 错误的能力(反之亦然),但大多数 E_STRICT 的错误是在编译时被评估的, 所以不会在文件中被报告。

Tip

传入 -1 的值将尽可能显示所有错误, 甚至包括将来 PHP 可能加入的新的错误级别和常量。 至 PHP 5.4,常量 E_ALL 有同样的行为。

参见

OK,知道解决办法之后再将其扔入文件里,大功告成。

至此,最近的问题都解决了。我们有时从错误中学到的东西,可能比从美德中学到的还要多。所以以后再遇到问题时,应该放缓自己的心态,虽然对于我来说很难。因为Coder在遇到BUG时心路历程绝大多数应该是这样的:

  • 我X,哪个傻X动我代码了?!
    • $ git log
    • commit XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (HEAD -> master, origin/master, origin/HEAD)
    • Author: 我自己 <woziji@monianhello.com>
    • Date: 就刚才 +0000
  • 哦,是我这个傻X啊...