-
1 # 都市心聲
-
2 # 一一哥Sun
你這個問題已經把需求說明的很清楚了，”某個查詢方法應當返回一條記錄，但是查出來多條“！也就是說，你的這個查詢只應該有一個結果，但是在此時或者某些時候有了多個結果，那麼就說明你的這個業務介面可能不符合冪等性要求啊。根據冪等性設計原則，無論你怎麼查，只要引數一樣，返回結果應該一樣。
那麼對於這種問題該怎麼解決，丟擲異常？返回多條中的第一條？
我覺得都不是很完美的解決方案。
拋異常，這是有些人的一種解決方式，但是問題解決了嗎？沒有啊！問題還在那裡，下次觸發了這個條件，還是會拋異常。這就好比說，森林裡有隻虎，有一天吃了人，然後你不去解決老虎，只是在森林裡掛了個牌子說：慎入，裡面有虎！這......
然後返回多個結果中的第一條，其實這也不是一種好辦法，可能本就應該只返回一條，為什麼查詢到了多個呢？你資料庫裡資料的唯一性做了校驗了嗎？不說別的，每次都查詢多個結果然後拿第一條資料，你不覺得這很影響效率嗎？
所以要從根源上解決問題！為什麼會導致資料有多條？該人工排查資料就人工排查，該加鎖就加鎖，儘可能保證查詢時入參一樣，結果也一樣！
-
3 # 極客架構
異常是什麼？程式執行過程中超出預期行為都屬於異常。在進行運算（ computation）時，出現例外的情況（需要特殊處理的非常規或例外的情況）對應的處理，這種情況經常會破壞程式正常的流程。它通常由特殊的程式語言結構、計算機硬體機制（如：中斷或者如訊號等作業系統IPC設施）所構成的。具體實現由硬體和軟體自身定義而決定。一些異常，尤其是硬體，將會在被中斷後進行恢復。如果某個查詢方法應當返回一條記錄，但是查出來多條應該如何處理？
程式設計的第一要求就可以保證使用者的正常使用。應當返回一條資料，但出現了多條資料，出現這種情況有很多種原因，業務出現問題，資料本身出現髒資料。
此時最好的處理方式，應該保證程式的正常執行，記錄告警訊息。需要有檢查異常訊息的機制，可以及時跟蹤異常日誌。
-
4 # 瘋喵
具體業務具體分析，兩害相比取其輕。
1，拋異常使用者就看不到資料，感覺很不爽，說你不專業，可能對公司形象有不利影響。
2，取第一條資料可能，
得到正確的結果，皆大歡喜
得到錯誤的結果，這個資料錯誤除了讓使用者一頭霧水，沒啥糟糕的結果。
得到錯誤的結果，但會造成錯誤進一步擴大，比如做出錯誤的決策，一條錯誤資料會導致產生多條錯誤資料，那可能會付出更多的時間去糾正錯誤資料，得不償失。
你可以讓使用者不爽，但不能給使用者造成損失
你可以適當讓使用者發發牢騷，但不要給自己找太多的麻煩
但一定要在第一時間得到通知，記日誌，發郵件，在使用者反應過來之前改掉。
-
5 # 夶白兎
根據你的描述，返回多條資料已經屬於“意外”，符合異常的使用標準，異常不會使程式碼變得“難看”，相反會使程式更加“健壯”。
-
6 # 哥才是瀋陽老王
這種問題沒有統一答案，要具體問題具體分析。但預期只有一條，那一定要查出原因。應急解決辦法就是取第一條就完事了。
-
7 # SuperVer
這個要看情況了。
遇到這樣的情況，底層程式碼最好封裝一個findOnlyOne的辦法，該拋的異常就應該拋。
但是上面的服務層就要看情況了，由於每個服務的類都有其各自的職責，並且上述這種情況是已知異常，如果：
2、但是大多數情況，捕獲異常的類並不知道應該怎麼處理這個異常，那就只能繼續往外拋，期待外面一層的服務層的類可以處理這個異常。如果不做任何區分直接像情況1一樣閉著眼睛處理掉，就會讓使用者產生沒有髒資料的錯覺，這個很危險。
3，如果所有服務層的類都不知道怎麼處理這個異常，那隻能交給控制器封裝一個友好點的話術提示使用者，透過人工干預的手段人工判斷和處理了
有人說，這是業務應該處理的問題，說的是不錯，但是難道業務梳理清楚了，程式就不需要任何控制了嗎？萬一被攻擊了呢？萬一被篡改了呢？
-
8 # 群山裡的小山山
工作中經常出現這種現象，很多都是邏輯刪除造成的，而介面開發人員又比較懶，不想重寫介面，導致可能存在下面的情況：某個地方需要顯示使用者的某一條最新資料，結果介面返回了一個list，在後端不想動的情況下，前端取最新一條就好了（最好後端排序再給你，一般取第一條），起碼保證業務上可用，同時也有更好地相容性。當然，如果約束更嚴格的話，那後端應該只返回一條，這就要看開發的規範了！
-
9 # 糖果爸教電腦
這個要看業務場景。從體驗角度來說，非必要不要拋異常，你可以隨機取並且通知自己，再排查多出資料的場景，並且處理。如果涉及資料安全問題，比如兩個使用者串號，那就拋異常。
-
10 # 已經被註冊換你
看業務，如果業務要求嚴謹性高，就拋異常或者返回錯誤，總之不繼續執行，反之可以按照優先順序比如時間倒序啦之類的取第一條，然後在在列印錯誤日誌或者新增警告資訊。但是也有一種情況就是，看你用的selectList,還是selectOne如果，取一條資料時習慣使用one那麼如果返回多條會自動丟擲異常，但是要做好處理
回覆列表
不知道大家有沒有看過《少年包青天》，這部經典的中國產懸疑推理片告訴我們一個道理，不管遇到什麼樣的問題，總有它的起因，當然最終也會塵埃落定，因為真相只有一個。
同樣的，在我們寫程式的時候也會遇到這樣那樣的問題（或者說Bug更符合擼碼身份），有時候我們會很煩，甚至想要一度地忽視它，但是它就像一顆雷一樣地暗藏在那裡，隨時都有可能爆掉，可能在除錯的時候，也有可能在測試的時候，當然更有可能在上線的時候。
雖然我們總是掩耳盜鈴般地慰藉自己，沒事的，一個小小的Bug而已，影響不大，但有時候就是因為這個小小的Bug可能會損失慘重，這不是誇大其詞，真的是真人真事，曾經有同事因為電話號碼位數的設定不合理，導致手機沒法接撥部分國外地區的電話，從而使得已量產的手機全部返工，損失不小。
所以不管遇到什麼樣的問題，我們都不要抱僥倖心理，要知道墨菲定律無時無刻都在我們身邊，我們要儘量杜絕所有可能發生的情況，特別是不要忽視已經出現的問題。
實戰剖析一、丟擲異常，問題復現
我們假設自己就是那個線上正在操作的幸運兒，操作得正嗨的時候，突然嘣地一聲給你彈了個異常提示框，然後怎麼辦？火急火燎地找客服，然後客服把問題反饋給測試驗證，本地驗證沒問題啊，還是叫開發看一下吧，開發看了錯誤日誌，基本鎖定是資料庫查詢出問題了，本來用的是selectOne方法查詢的，結果查出來的是List，從而導致異常。
在這裡，可能有的小夥伴就建議，沒事幹嘛拋個異常呀，太不友好了，如果有多條記錄，叫開發取最新的那條就好了，對此，我想說，遇到問題，我們要虛心接受並著手解決，而不是規避或逃避問題，當只能有一條記錄的時候，那無論如何都得有且只有一條，而不能特意地去投機取巧，不然可能會爆發更嚴重的問題。
除此之外，我們也要安撫一下那個幸運兒的情緒，並且在一定的酌情考慮下，可以廣發英雄帖，發現問題者給予一定的獎勵，我想大部分的幸運兒都樂意為之的。二、查詢問題根源
發現問題後，開發就百思不得其解，這明明只會有一條記錄的啊，怎麼會在資料庫出現多條呢，哪裡出了問題，程式碼？人工？誤操作？根據我多年的經驗以及曾經遇到過類似的問題，來說說可能的情況。
1、有人誤動了資料庫，人為地添加了多條資料。（一般人可能沒這個許可權，可能性小）
2、新增該記錄的介面操作引起。（如果沒處理好，高併發情況下可能性很大）
3、其它定時或其它介面操作引起。（如果查詢的記錄所在的資料庫表在其它介面也使用，那這種可能性還是存在的）
以上幾點最有可能的是第2點，因為在高併發的情況下，如果沒有把鎖處理好，以及網路延遲的情況下是很可能同時插入多條資料的。
三、解決問題
查到了問題的根源，我們就應該一一排查及解決問題，這才是最終問題塵埃落定的時候。
1、核查人員，查詢記錄，確認無人動資料庫。
2、在新增記錄的時候，特別是高併發場景，一定要設好互斥鎖，要麼做悲觀鎖，要麼做樂觀鎖，要麼透過快取來儲存該操作動作，確保某一時刻只有一次操作，然後資料庫可以根據某個欄位做一下唯一鍵控制。
3、仔細檢視及分析其它可能引起該記錄所在資料庫表的操作程式碼。
經過以上幾點排查及處理，我想問題應該已經壽寢正終了。
總結作為程式猿，遇到Bug不用怕，這只是正常的情況而已，如果開發一個專案一點Bug都沒有，那就真的不敢想象了，遇到問題，查詢原因，解決問題，這才是我們該做的。