Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

让错误来得更猛烈些吧

  无论多么优秀的程序总是会出现意外的错误。即使对自己的程序很有把握,但环境永远是无法稳定的。以前用 Windows 的时候经常写一些小工具自己用,从来没出过问题。但分享给别人时总是遇到各种奇怪的问题,比如被某某安全卫士杀掉之类的。
  Web 程序也同样,谁知道客户端的浏览器是什么诡异的配置。谁知道网络提供商会不会劫持什么东西。总之,容错很重要。一个好的程序即使遇上奇葩的情况也应该要容错,并将用户引导会正确的操作流程中。
  其实很多开发者对环境级的错误都是睁一只眼闭一只眼的。反正自己能跑通程序,QA 能跑通程序,大部分用户能跑通程序,一切就安好。其实我也不愿意为这些奇葩的环境做兼容,但是我所说的容错并不是功能兼容,而且一种用户引导。比如我不兼容 IE6,那么 IE6 用户来访问我也不会给一坨错误的东西,而是跳到一个浏览器升级的页面并提示用户升级浏览器。
  客户端环境出问题的情况其实能预见的也就那么几种,更多的奇葩错误来自网络。比如请求一个 API 产生的网络错误,那么此时程序应该做什么处理?经常看到一些程序白屏或无限菊花,就是因为没考虑意外的网络错误。如果每次网络错误都能适当地重试并给用户一个操作提示,体验就可以明显提升。其实很多 App 里都有这种设定,比如 QQ 掉线时会显示「世界最远的距离就是没网」,这就挺好的。然而 Web 目前还没这种行业习惯,所以无限菊花在 Web 上随处可见。
  网络错误也是一种比较容易预见的问题。API 响应错误这种不太容易发现的错误才是个坑。我自己写程序也经常把 API 响应结果视为「必然正确」的东西。比如 API 约定的格式是 JSON 的话一般就不会处理 API 响应一个非 JSON 的情况。 然而 API 也是人做的,总是可能存在问题。比如以前某个 API 本来约定 0 表示 false,1 表示 true 的。结果出现了 2、3、4 等各种奇怪的值,然后就呵呵了。
  我觉得在开发时应该为所有可能出现的错误都做处理,有些错误处理给以改善用户体验,有些错误处理可以在出 BUG 时更快地定位到问题所在。而与其相对的是「屏蔽错误」,这才是最蠢的做法。即使没有处理错误,抛出的错误也很容易调试。而如果把所有错误屏蔽掉,那可能是出了错自己都找不到问题。
网名:
3.84.186.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^