小伙伴好哇,我是Tom哥。
今天分享一個(gè)寫(xiě)代碼時(shí)遇到的詭異問(wèn)題,如何排查解決的。
從事互聯(lián)網(wǎng)的人都懂,一般遇到問(wèn)題時(shí),首先會(huì)想用谷歌、百度等搜索引擎,看看前輩們是如何解決的。
但有些問(wèn)題比較抽象,不知道如何來(lái)描述,怎么辦?或者勉強(qiáng)描述清楚了,搜出來(lái)的答案也很難滿足要求,整個(gè)過(guò)程猶如大海撈針。最后求助 ChatGPT 瞬間解決,給大家分享下解決思路。
正在開(kāi)發(fā)一個(gè)項(xiàng)目,倉(cāng)儲(chǔ)層有一個(gè)接口類(IProductReadRepository),其中一個(gè)方法的入?yún)⑹褂昧?Java 泛型,具體如下:
List<SpuVO> batchQuerySpuBySpuIdsFromDB(ProductQueryWrapper<List<Long>> req);
在上層的領(lǐng)域服務(wù)中,有一處調(diào)用這個(gè)方法的代碼,具體如下:
ProductQueryWrapper productQueryWrapper = ProductQueryWrapper.builder() .bizCode(BusinessCodeEnum.SMART.getCode()) .bizScene(BusinessSceneEnum.RETAIL.getCode()) .storeId(multiPackageVO.getStoreId()) .bizParams(spuIds) .build();List<ProductSummaryVO> productSummaryVOS = productReadRepository.batchQuerySpuBySpuIdsFromDB(productQueryWrapper);if (CollectionUtils.isEmpty(productSummaryVOS)) { bizResult.error(BizErrorCode.MULTI_PACKAGE_PRODUCT_NOT_EXIST); return bizResult;}
其中,List<ProductSummaryVO> productSummaryVOS = productReadRepository.batchQuerySpuBySpuIdsFromDB(productQueryWrapper); 這行代碼非常詭異
返回的結(jié)果List<ProductSummaryVO>并不匹配,但在IDEA中卻沒(méi)有報(bào)錯(cuò),這讓我們感到非常困擾。
這是怎么回事?
當(dāng)時(shí)懷疑是錯(cuò)覺(jué),仔細(xì)對(duì)比了兩個(gè)方法,確實(shí)是對(duì)的。
又懷疑是 IDEA 的緩存干擾導(dǎo)致,所以將工程重新 build 了一次還是不行!
接下來(lái),能想到的各種招數(shù)都招呼上,比如:
最后,使出絕招,將本地的工程代碼全部刪除,然后重新從 git 上拉取最新代碼,編譯,導(dǎo)入到 IDEA 工程。
但,但,但,問(wèn)題依然存在,真讓人崩潰。
難道是 IDEA 中的錯(cuò)誤檢查失效了,于是人為制造了一些錯(cuò)誤,發(fā)現(xiàn) IDEA 也都能識(shí)別出來(lái)。
實(shí)在沒(méi)招了。。。。。。。
最后,還是問(wèn)下 ChatGPT 吧
首先,先把問(wèn)題描述清楚,ChatGPT 特懂人情世故,你跟他講清楚問(wèn)題,他也會(huì)給你一個(gè)清楚的答案。
有一個(gè)接口內(nèi)的方法定義如下: List<SpuVO> batchQuerySpuBySpuIdsFromDB(ProductQueryWrapper<List<Long>> req);使用下面的代碼來(lái)調(diào)用 batchQuerySpuBySpuIdsFromDB,返回的 List<SpuVO> 結(jié)果并不匹配,但在 IDEA 中沒(méi)有報(bào)錯(cuò),是什么原因?ProductQueryWrapper productQueryWrapper = ProductQueryWrapper.builder() .bizCode(BusinessCodeEnum.SMART.getCode()) .bizScene(BusinessSceneEnum.RETAIL.getCode()) .storeId(multiPackageVO.getStoreId()) .bizParams(spuIds) .build();List<ProductSummaryVO> productSummaryVOS = productReadRepository.batchQuerySpuBySpuIdsFromDB(productQueryWrapper);if (CollectionUtils.isEmpty(productSummaryVOS)) { bizResult.error(BizErrorCode.MULTI_PACKAGE_PRODUCT_NOT_EXIST); return bizResult;}
ChatGPT 很快就給出了答案。
問(wèn)題可能出在泛型擦除和編譯時(shí)類型檢查上。由于Java泛型的擦除機(jī)制,在運(yùn)行時(shí)無(wú)法獲取泛型的實(shí)際類型,這可能導(dǎo)致類型不匹配的問(wèn)題。
那我們就按照它的思路來(lái),將這行代碼 ProductQueryWrapper productQueryWrapper = ProductQueryWrapper.builder()
修改為 ProductQueryWrapper<List<Long>> productQueryWrapper = ProductQueryWrapper.<List<Long>>builder()
在構(gòu)建 ProductQueryWrapper 對(duì)象時(shí), 指定泛型參數(shù)的具體類型,以便在運(yùn)行時(shí)能夠正確地識(shí)別參數(shù)類型。
然后,問(wèn)題真的解決了。
如下圖所示,第二處紅框位置的代碼開(kāi)始報(bào)錯(cuò)。因?yàn)榻涌诘囊?guī)范(返回結(jié)果)調(diào)整了,此處確實(shí)應(yīng)該報(bào)錯(cuò)提示。
后面,我們根據(jù)錯(cuò)誤提示,將 ProductSummaryVO 類替換成 SpuVO 類。
最終,不但編譯不報(bào)錯(cuò),單元測(cè)試也能跑通。問(wèn)題完美解決。
為何在 IDEA 中沒(méi)有直接報(bào)錯(cuò)呢?這里牽扯到Java泛型的類型推斷機(jī)制。
上述代碼中,雖然使用了原始類型 ProductQueryWrapper ,但沒(méi)有指定具體的泛型類型。
Java 7 及以后的版本引入了菱形操作符(Diamond Operator),允許在創(chuàng)建對(duì)象時(shí)不再重復(fù)指定泛型類型,而是通過(guò)上下文進(jìn)行類型推斷。
這就意味著在你的代碼中,雖然沒(méi)有明確指定泛型類型,但由于在 ProductQueryWrapper.builder() 上下文中,編譯器會(huì)嘗試根據(jù)調(diào)用方的期望類型來(lái)推斷泛型參數(shù)。
這種類型推斷機(jī)制使得在 IDEA 開(kāi)發(fā)工具不會(huì)直接報(bào)錯(cuò),也就出現(xiàn)了上文說(shuō)到的那個(gè)問(wèn)題。
今天的分享就到這里,我們下回再見(jiàn)。
本文鏈接:http://www.www897cc.com/showinfo-26-57393-0.html代碼出錯(cuò)了,IDE竟然不報(bào)錯(cuò)?太詭異了....
聲明:本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí),若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除處理。郵件:2376512515@qq.com
上一篇: Spring國(guó)際化的應(yīng)用及原理詳解
下一篇: Elasticsearch 8.X 小技巧:使用存儲(chǔ)腳本優(yōu)化數(shù)據(jù)索引與轉(zhuǎn)換過(guò)程