为什么你的应用程序需要崩溃

2019独角兽企业重金招聘Python工程师标准>>>

翻译之前想说一下,我英文渣的很,文章含金量感觉不是很高,主要为了锻炼自己的英文,但是很多东西还是不会翻译,希望有志同道合的人能互相交流下,提高下英文水平,多谢

翻译自 Jeroen Mols 的 Why your app should crash

很多时候我看到开发人员试图不惜一切代价避免崩溃。 但未处理的异常真的那么糟糕吗? 非空检查是真的答案吗? 实际上,有时你想让你的应用程序崩溃。 这篇文章将解释为什么,给一些实用的建议。

序言

在这篇文章中,为简单起见我重点说下非空检查,但是这样做很容易让被理解成边缘情况

非空检查结构

假设我们有一个简单的应用程序,它显示了一个运动员的list

public void showPlayers(List<Player> soccerPlayers) {
  // some awesome code here
}

在一个正常的场景中,这将可以工作,但如果该list为空的时候会发生什么呢? 显然可以添加一个臭名昭著的非空检查

public void showPlayers(List<Player> soccerPlayers) {
  if (soccerPlayers == null || soccerPlayers.isEmpty()) return;

  // some awesome code here
}

所有都搞定了! 哦,等一下…… list也可以是空的

public void showPlayers(List<Player> soccerPlayers) {
  if (soccerPlayers == null || soccerPlayers.isEmpty()) return;

  // some awesome code here
}

那五层的结构的 soccerPlayers 下面通过UI怎么办? 我们还应该在那些层中的每一层重复我们的检查吗？ 不知不觉间,你就会觉得非空检查无处不在!

非空检查问题

显然,明显非空检查代码杂乱。 但这并不是唯一的问题! 因为一旦你习惯使用它们,你将使他们无处不在!

public void showPlayers(List<Player> soccerPlayers) {
  if (soccerPlayers == null) return;

  if (myRecyclerView == null) return;

  if (myRecyclerView.getAdapter() == null) return;

  // some awesome code here
}

即使你不需要他们,你仍然将它们添加! 让它沉在一秒钟…… 这里的问题是什么?

“无害的”空检查可以轻易地掩盖一个更大，更基本的问题

首先出现 soccerPlayers 的地方实际上可以是空的吗? 或者它是你应用程序里较低级别的响应，以返回一个空的list？ 当soccerPlayers 实际上是空的时候会发生什么呢? 一定是展示给用户一个完全空白的屏幕,对吧?

后者实际上意味着你的应用程序将默默的停止工作在生产环境下而你没有任何方式检测他!

解决崩溃

如果一个app进入了不是设计想要的状态,,它应该崩溃。 这没有一般的处理方式。

这个方法不应该在理论上可以发生的每一个可能出现的地方都去检查,相反, 方法不应该检查他们的输入每一个可能的场景,理论上可以发生。 相反,你应该仔细考虑实际会输入什么,只有这样的情况才去准备那样做(非空检查)。

如果你的app得到一个不是设计要的状态的时候,难道你不想尽快知道到底发生了什么事情吗

好，在来看看我们心爱的exceptions！

未处理的异常是伟大的,因为他们:

• 通知你马上要崩溃的应用
• 高亮的问题,而不是静静的等待杀死
• 有跟踪记录可以确定问题
• 自动备份到你的崩溃报告

这显然不意味着你的应用程序应该崩溃为您的用户！ 我想说的是,如果有一个问题在我的应用程序,我宁愿通过崩溃报告获取,而不是不知道。

崩溃或者不崩溃对用户的结果都是一样的,他们的app程序有问题.

放心,你不会开始就让更多的崩溃困扰用户! 发布版本之前你还有几个安全网:开发人员测试、QA部门,测试,分阶段发布,……

所以即使有这个策略，你仍然可以得到99,9％崩溃免费用户。

实用技巧

阐明这种方法并帮助您启动实施:

• 始终将您的app设计为对于您的控制之外的任何输入都是稳健的：来自Web服务的响应，在UI中输入的数据，传入的意图，
• 确保应用中输入的数据完整性。这种方式的无效数据（null，空，...）不能发生在你的应用程序的任何其他地方，你不必检查它。 - 任何地方,你都不需要检查。
• 如果你不确定某个错误情况可能发生在某个地方，假设它不会！在测试过程中，如果你是对的你会发现（RuntimeException）
• 如果某个方法在生产环境中无法调用，只能调用一次，...抛出IllegalStateException。
• 在向所有用户发布前，请务必进行彻底测试。在用户之前做，你会遇到可怕的“崩溃”。

总结

不要害怕崩溃，你应该拥抱他们在你的应用程序中更快的发现错误。 崩溃不仅使错误立即可见，它们还提供了一种方便的通过stacktrace调试它们的方法。

转载于:https://my.oschina.net/wenlongguo/blog/858712