Android SDK開發藝術探索（二）Exception or ErrorCode

1、前言

本篇是Android SDK開發藝術探索系列的第二篇文章，介紹了Java/Android中的異常以及在SDK開發中是如何根據異常的特性進行融合設計的思考。注意，本篇並不涉及詳細地異常介紹以及異常發生後代碼執行地順序問題，而是基於異常的基本特性與職責邊界，結合業務開發的實際狀況，試圖探討拋異常與錯誤碼的選擇。

系列文章：

Android SDK開發藝術探索（一）開篇與設計

Android SDK開發藝術探索（二）Exception or ErrorCode

Android SDK開發藝術探索（三）初始化

Android SDK開發藝術探索（四）個性化配置

Android SDK開發藝術探索（五）安全與校驗

Android SDK開發藝術探索（六）壓縮與優化

Android SDK開發藝術探索（七）依賴原則與打包方法

2、異常的概念

首先，咱們來認識一下異常：

異常是指在程序運行期間發生的意外事件，它會中斷程序（當前方法或做用域）正常執行的流程。

• Checked Exception，好比最多見的IOException，這種異常是指須要調用處顯式處理的類型，要麼用try catch捕獲，要麼用 throw 再拋出去；
• Unchecked Exception指的是全部繼承自Error（包含自身）或者RuntimeException（包含自身）的類，好比咱們常見的NullPointerException就屬於這類。這些異常不強制在調用處顯式處理，可是也能夠經過try catch處理；
• Throwable是Exception和Error的父類。

2.一、APP開發者看待異常的角度

在APP的開發中，彷佛咱們老是被動的根據編譯器的提示編寫異常代碼，只是爲了讓編譯器經過。爲何編譯器跟咱們過不去？由於這些提示都是由於對於的操做拋出了Checked類型的異常，須要手動顯式進行處理。

在Java開發中，NullPointerException，有部分人簡稱NPE，是每一個開發者都很熟悉的異常，也是讓人深惡痛絕的異常。

Java程序員：要麼正在debug NPE，要麼就在debug NPE的路上。

2.二、SDK開發者看待異常的角度

在SDK開發中，除了要面臨APP開發中那些對異常的處理，還須要充分考慮被異常中斷了的那些邏輯對總體交互流程產生的影響。

SDK自身的邏輯與APP密不可分，假如由於SDK內部發生的異常，中斷了SDK內部流程，而又未告知APP這顯然是不可接受的。所以，咱們必須謹慎處理SDK內部發生的異常，原則是不該該把異常內部消化，而應該向外拋出，以一樣異常的形式或者自定義的返回碼。

2.三、Exception or ErrorCode，這是一個問題

在SDK的邏輯設計中，既能夠經過異常告知開發者，也能夠經過返回碼告知開發者，那麼如何選擇呢？下面咱們經過兩個例子來探索處理的方式

• **場景1：**在SDK的入參中，須要APP傳入手機號碼，並校驗參數合法性
• 場景2： 在SDK內部，須要獲取APP ID並進行白名單校驗

這兩種場景下，都須要在SDK的調用流程中處理並反饋，而反饋能夠經過返回碼，也能夠直接拋異常（系統內置異常或自定義異常）孰好孰壞？

筆者認爲，在咱們實際的SDK開發中，應該經過對相關錯誤進行分類，來決定採用異常交互仍是返回碼交互

自定義異常是一種比較「重」的告知方式，由於異常意味着中斷。返回碼是一種比較「輕」的告知方式，也是最不容易引發開發者重視的告知方式。

常見SDK開發者沒有清晰的返回碼對照表，亦常見APP開發者沒有完整地處理所有返回情形。所以，不可逆轉的錯誤建議採用異常處理機制，直接中斷程序執行流程讓問題完全暴露出來，避免發生更多預期以外的錯誤。

具體歸納爲：

在與業務有關的邏輯且涉及用戶（注意，非開發者，下同）能夠重試的部分，應該採用返回碼告知開發者，方便其進行後續處理。好比，用戶輸入了不符合手機號碼規則的信息，就能夠經過咱們的自定義檢查邏輯來返回對應的返回碼，集成SDK的開發者針對處理便可。

在與業務無關的邏輯且一旦發生用戶沒法自行處理的部分，能夠採用拋出自定義異常的處理方式。好比，SDK開發着對APP的包名校驗，這是一個面向開發者的校驗邏輯，所以不妨直接拋出自定義異常，坦然讓APP崩潰，讓開發者從錯誤堆棧信息中找到問題。這種情形，也許就是Unchecked Exception的使用場景吧。

Exception or ErrorCode，這個問題想必你們也有了一個感性認識，也歡迎耐心看至此處的讀者發表本身的看法。

3、結語

本篇主要是回顧了一下異常的概念，探討了異常在SDK開發中的使用處理問題。總結起來：

1. 針對用戶形成的無效參數等可重試的邏輯異常，應該經過返回碼交互；
2. 針對開發者未遵照約定形成的沒法重試的專有異常，應該經過直接拋異常退出程序，由於此類型錯誤不該該讓用戶接觸，也沒有繼續業務流程的必要；

接下來將繼續探討SDK開發中的初始化設計,包括初始化的幾種方式，初始化對APP啓動的影響，順便介紹SDK開發歷程中因爲誤入歧途而瞭解到的Java雙重繼承實現。

最後，若是本篇文檔對您的開發有所幫助或啓發，點贊/關注/分享三連就是對做者持續創做最好的激勵，感謝支持！

參考文章

• Exceptions in Java
• 優雅的處理你的Java異常
• Tutorial exceptions definition

版權聲明：

本文首發於個人專欄 AndDev安卓開發 已受權鴻洋公衆號獨家發佈。