2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

翻譯之前想說一下,我英文渣的很,文章含金量感覺不是很高,主要為了鍛煉自己的英文,但是很多東西還是不會(huì)翻譯,希望有志同道合的人能互相交流下,提高下英文水平,多謝

翻譯自 Jeroen Mols 的 Why your app should crash

很多時(shí)候我看到開發(fā)人員試圖不惜一切代價(jià)避免崩潰。 但未處理的異常真的那么糟糕嗎? 非空檢查是真的答案嗎? 實(shí)際上,有時(shí)你想讓你的應(yīng)用程序崩潰。 這篇文章將解釋為什么,給一些實(shí)用的建議。

序言

在這篇文章中,為簡單起見我重點(diǎn)說下非空檢查,但是這樣做很容易讓被理解成邊緣情況

非空檢查結(jié)構(gòu)

假設(shè)我們有一個(gè)簡單的應(yīng)用程序,它顯示了一個(gè)運(yùn)動(dòng)員的list

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

在一個(gè)正常的場景中,這將可以工作,但如果該list為空的時(shí)候會(huì)發(fā)生什么呢? 顯然可以添加一個(gè)臭名昭著的非空檢查

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 }

那五層的結(jié)構(gòu)的 soccerPlayers 下面通過UI怎么辦? 我們還應(yīng)該在那些層中的每一層重復(fù)我們的檢查嗎？ 不知不覺間,你就會(huì)覺得非空檢查無處不在!

非空檢查問題

顯然,明顯非空檢查代碼雜亂。 但這并不是唯一的問題! 因?yàn)橐坏┠懔?xí)慣使用它們,你將使他們無處不在!

public void showPlayers(List<Player> soccerPlayers) {if (soccerPlayers == null) return;if (myRecyclerView == null) return;if (myRecyclerView.getAdapter() == null) return;// some awesome code here }

即使你不需要他們,你仍然將它們添加! 讓它沉在一秒鐘…… 這里的問題是什么?

“無害的”空檢查可以輕易地掩蓋一個(gè)更大，更基本的問題

首先出現(xiàn) soccerPlayers 的地方實(shí)際上可以是空的嗎? 或者它是你應(yīng)用程序里較低級(jí)別的響應(yīng)，以返回一個(gè)空的list？ 當(dāng)soccerPlayers 實(shí)際上是空的時(shí)候會(huì)發(fā)生什么呢? 一定是展示給用戶一個(gè)完全空白的屏幕,對(duì)吧?

后者實(shí)際上意味著你的應(yīng)用程序?qū)⒛耐Ｖ构ぷ髟谏a(chǎn)環(huán)境下而你沒有任何方式檢測他!

解決崩潰

如果一個(gè)app進(jìn)入了不是設(shè)計(jì)想要的狀態(tài),,它應(yīng)該崩潰。 這沒有一般的處理方式。

這個(gè)方法不應(yīng)該在理論上可以發(fā)生的每一個(gè)可能出現(xiàn)的地方都去檢查,相反, 方法不應(yīng)該檢查他們的輸入每一個(gè)可能的場景,理論上可以發(fā)生。 相反,你應(yīng)該仔細(xì)考慮實(shí)際會(huì)輸入什么,只有這樣的情況才去準(zhǔn)備那樣做(非空檢查)。

如果你的app得到一個(gè)不是設(shè)計(jì)要的狀態(tài)的時(shí)候,難道你不想盡快知道到底發(fā)生了什么事情嗎

好，在來看看我們心愛的exceptions！

未處理的異常是偉大的,因?yàn)樗麄?

• 通知你馬上要崩潰的應(yīng)用
• 高亮的問題,而不是靜靜的等待殺死
• 有跟蹤記錄可以確定問題
• 自動(dòng)備份到你的崩潰報(bào)告

這顯然不意味著你的應(yīng)用程序應(yīng)該崩潰為您的用戶！ 我想說的是,如果有一個(gè)問題在我的應(yīng)用程序,我寧愿通過崩潰報(bào)告獲取,而不是不知道。

崩潰或者不崩潰對(duì)用戶的結(jié)果都是一樣的,他們的app程序有問題.

放心,你不會(huì)開始就讓更多的崩潰困擾用戶! 發(fā)布版本之前你還有幾個(gè)安全網(wǎng):開發(fā)人員測試、QA部門,測試,分階段發(fā)布,……

所以即使有這個(gè)策略，你仍然可以得到99,9％崩潰免費(fèi)用戶。

實(shí)用技巧

闡明這種方法并幫助您啟動(dòng)實(shí)施:

• 始終將您的app設(shè)計(jì)為對(duì)于您的控制之外的任何輸入都是穩(wěn)健的：來自Web服務(wù)的響應(yīng)，在UI中輸入的數(shù)據(jù)，傳入的意圖，
• 確保應(yīng)用中輸入的數(shù)據(jù)完整性。這種方式的無效數(shù)據(jù)（null，空，...）不能發(fā)生在你的應(yīng)用程序的任何其他地方，你不必檢查它。 - 任何地方,你都不需要檢查。
• 如果你不確定某個(gè)錯(cuò)誤情況可能發(fā)生在某個(gè)地方，假設(shè)它不會(huì)！在測試過程中，如果你是對(duì)的你會(huì)發(fā)現(xiàn)（RuntimeException）
• 如果某個(gè)方法在生產(chǎn)環(huán)境中無法調(diào)用，只能調(diào)用一次，...拋出IllegalStateException。
• 在向所有用戶發(fā)布前，請(qǐng)務(wù)必進(jìn)行徹底測試。在用戶之前做，你會(huì)遇到可怕的“崩潰”。

總結(jié)

不要害怕崩潰，你應(yīng)該擁抱他們?cè)谀愕膽?yīng)用程序中更快的發(fā)現(xiàn)錯(cuò)誤。 崩潰不僅使錯(cuò)誤立即可見，它們還提供了一種方便的通過stacktrace調(diào)試它們的方法。

轉(zhuǎn)載于:https://my.oschina.net/wenlongguo/blog/858712

總結(jié)

以上是生活随笔為你收集整理的为什么你的应用程序需要崩溃的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。