我有像下面這樣的 JSON{ "a1": "aaa", "b1": 333, "c1": { "c1": "ccc", "d1": "ddd", "f1": [ {"a1": "xyz"}, {"b1": "lmn"}, {"c1":123.00} ] }}我正在將文件讀入 String 并創(chuàng)建一個 JSONObject ，如下所示JSONObject json = new JSONObject(new JSONTokener(str));JSON 是從外部傳入我的應(yīng)用程序的，因此內(nèi)容有時可能會非常不同。假設(shè)它可以完全為空，或者某些元素可以為空，或者數(shù)組大小可以為 0 或 1 或更多等等。當(dāng)我處理 JSONObject 時，我可以使用以下命令繼續(xù)檢查所有元素json.has and !=null 這樣它就不會拋出任何異常。我可以得到如下代碼if( json.has("c") && json.getJSONObject("c")!= null && json.getJSONObject("c").has("f") && json.getJSONObject("c").getJSONArray("f").length() > 1 &&json.getJSONObject("c").getJSONArray("f").getJSONObject(1).has("b") ){ String x = json.getJSONObject("c").getJSONArray("f").getJSONObject(1).getString("b"); }這使得代碼具有一長串 if 條件。不過我想我可以用 try catch 將語句括起來try { String x = json.getJSONObject("c").getJSONArray("f").getJSONObject(1).getString("b"); }catch(JSONException e) { //log and proceed }請建議在這種情況下是否有任何有效的理由來放置很長的 if 條件，而不是僅僅嘗試 - 捕獲 - 記錄并繼續(xù)。您還可以分享一下使用 JSONException 在這種情況下有什么“優(yōu)點(diǎn)”嗎？
3 回答
飲歌長嘯
TA貢獻(xiàn)1951條經(jīng)驗(yàn) 獲得超3個贊
選項(xiàng) 0：長 If 語句
我認(rèn)為這太復(fù)雜了，尤其是當(dāng)鏈條變得更長時。我會考慮使用遠(yuǎn)程類似解決方案的唯一情況是，如果用戶需要確切地知道問題出在哪里，并且有關(guān)于如何解決這個問題以及在非常特定的用例中如何發(fā)生這種情況的具體指南，但是在這種情況下如果您需要大量的 if 語句和 log 語句。
選項(xiàng) 1：嘗試捕獲
正如您所建議的那樣，Try-catch 確實(shí)是可能的，但是您需要確保捕獲當(dāng) JSON 字段不存在或類型錯誤時可能發(fā)生的所有可能的異常，例如 ClassCastException 和 NullPointerException。它很短但不是很優(yōu)雅，正如其他回答者所說可能隱藏其他異常（但您仍然可以記錄堆棧跟蹤）。
選項(xiàng) 2：Java 8 可選
另一種選擇是找到一個允許您使用 Java 8 可選類型的庫。例如，建議使用Jackson。這更優(yōu)雅，但也可以成為一個大型連鎖店。這也為您的項(xiàng)目增加了一種依賴。
選項(xiàng) 3：路徑表達(dá)式
第三種選擇是使用路徑表達(dá)式JsonPath，您可以將所有語句放入一個表達(dá)式中并獲取該表達(dá)式的所有結(jié)果。在我看來，這是完美的用例，也是迄今為止最好的解決方案。唯一的缺點(diǎn)是這會給您的項(xiàng)目增加一個依賴項(xiàng)。
拉莫斯之舞
TA貢獻(xiàn)1820條經(jīng)驗(yàn) 獲得超10個贊
請建議在這種情況下是否有任何有效的理由來放置很長的 if 條件，而不是僅僅嘗試 - 捕獲 - 記錄并繼續(xù)。
以下是幾個原因：
效率：創(chuàng)建、拋出和捕獲異常的成本相對較高。到底有多昂貴取決于版本，也可能取決于上下文。在最近的版本中，JIT 編譯器可以（據(jù)我所知）將某些序列優(yōu)化為條件分支。但是，如果您要記錄異常，那么 JVM 將必須創(chuàng)建一個異常對象并填充堆棧跟蹤，這是最昂貴的部分。
如果您登錄
NullPointerException：json.getJSONObject("c").getJSONArray("f").getJSONObject(1).getString("b")您可能無法判斷哪個組件丟失或?yàn)榭?。堆棧跟蹤中的行號不足以區(qū)分情況。（
JSONException異常消息將為您提供更多線索。）您也無法區(qū)分
jsonis 的情況null，這可能是另一種問題；即一個錯誤。如果您將其視為數(shù)據(jù)錯誤，則很難找到并修復(fù)代碼錯誤。如果您捕獲所有異常（如另一個答案所建議的），則可能會隱藏更多類別的錯誤。餿主意。
您還可以分享一下使用 JSONException 在這種情況下有什么“優(yōu)點(diǎn)”嗎？
唯一真正的“優(yōu)點(diǎn)”是它可能會減少代碼，特別是如果您可以將try ... catch放在很多這樣的代碼中。
最重要的是，您需要自己權(quán)衡這一點(diǎn)。其中一個因素是您獲得的 JSON 與代碼預(yù)期不符的可能性有多大。這部分取決于生成 JSON 的內(nèi)容。
斯蒂芬大帝
TA貢獻(xiàn)1827條經(jīng)驗(yàn) 獲得超8個贊
感謝上面的回復(fù)，下面是問題的解決方法。
JSONPath對于我提到的場景效果最好。
首先創(chuàng)建一個com.jayway.jsonpath.Configuration類型的配置對象
Configuration?conf?=?Configuration.builder().options(Option.SUPPRESS_EXCEPTIONS).mappingProvider(new?JsonOrgMappingProvider()).jsonProvider(new?JsonOrgJsonProvider()).build();
Option.SUPPRESS_EXCEPTIONS?- 這將有助于在元素丟失時抑制異常
mappingProvider(new JsonOrgMappingProvider()).jsonProvider(new JsonOrgJsonProvider()?- 這使用正確的提供程序，這樣當(dāng)我們解析 json 時，我們不需要將 JSONObject 轉(zhuǎn)換為 String，從而提供最佳性能。
DocumentContext?docContext?=?JsonPath.using(conf).parse(json);
如果我們使用默認(rèn)提供程序，那么我們需要如下解析 JSONObject
DocumentContext?docContext?=?JsonPath.using(conf).parse(json.toString());
然后讀取我使用的元素
docContext.read("$.a.b.c.d.values[0].e.f")現(xiàn)在性能也達(dá)到最佳狀態(tài)?；ㄙM(fèi)更多時間和內(nèi)存的原因是
我在循環(huán)中同時閱讀和解析。后來我將解析移出了循環(huán)。
我正在使用默認(rèn)提供程序并正在執(zhí)行 json.toString()
添加回答
舉報
0/150
提交
取消