日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

最近，我們的線上環(huán)境出現(xiàn)了一個(gè)問(wèn)題，線上代碼在執(zhí)行過(guò)程中拋出了一個(gè)IllegalArgumentException，分析堆棧后，發(fā)現(xiàn)最根本的的異常是以下內(nèi)容：

成都創(chuàng)新互聯(lián)公司致力于互聯(lián)網(wǎng)網(wǎng)站建設(shè)與網(wǎng)站營(yíng)銷，提供網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、網(wǎng)站開(kāi)發(fā)、seo優(yōu)化、網(wǎng)站排名、互聯(lián)網(wǎng)營(yíng)銷、微信小程序定制開(kāi)發(fā)、公眾號(hào)商城、等建站開(kāi)發(fā)，成都創(chuàng)新互聯(lián)公司網(wǎng)站建設(shè)策劃專家，為不同類型的客戶提供良好的互聯(lián)網(wǎng)應(yīng)用定制解決方案，幫助客戶在新的全球化互聯(lián)網(wǎng)環(huán)境中保持優(yōu)勢(shì)。

 
 
 
 

  
  
  
  
java.lang.IllegalArgumentException:  
  
  
  
  
 
  
  
  
  
No enum constant com.a.b.f.m.a.c.AType.P_M 
 
 
 
 

大概就是以上的內(nèi)容，看起來(lái)還是很簡(jiǎn)單的，提示的錯(cuò)誤信息就是在AType這個(gè)枚舉類中沒(méi)有找到P_M這個(gè)枚舉項(xiàng)。

于是經(jīng)過(guò)排查，我們發(fā)現(xiàn)，在線上開(kāi)始有這個(gè)異常之前，該應(yīng)用依賴的一個(gè)下游系統(tǒng)有發(fā)布，而發(fā)布過(guò)程中是一個(gè)API包發(fā)生了變化，主要變化內(nèi)容是在一個(gè)RPC接口的Response返回值類中的一個(gè)枚舉參數(shù)AType中增加了P_M這個(gè)枚舉項(xiàng)。

但是下游系統(tǒng)發(fā)布時(shí)，并未通知到我們負(fù)責(zé)的這個(gè)系統(tǒng)進(jìn)行升級(jí)，所以就報(bào)錯(cuò)了。

我們來(lái)分析下為什么會(huì)發(fā)生這樣的情況。

問(wèn)題重現(xiàn)

首先，下游系統(tǒng)A提供了一個(gè)二方庫(kù)的某一個(gè)接口的返回值中有一個(gè)參數(shù)類型是枚舉類型。

一方庫(kù)指的是本項(xiàng)目中的依賴

二方庫(kù)指的是公司內(nèi)部其他項(xiàng)目提供的依賴

三方庫(kù)指的是其他組織、公司等來(lái)自第三方的依賴

 
 
 
 

  
  
  
  
public interface AFacadeService { 
  
  
  
  
 
  
  
  
  
    public AResponse doSth(ARequest aRequest); 
  
  
  
  
 
  
  
  
  
} 
  
  
  
  
 
  
  
  
  
public Class AResponse{ 
  
  
  
  
 
  
  
  
  
    private Boolean success; 
  
  
  
  
 
  
  
  
  
    private AType aType; 
  
  
  
  
 
  
  
  
  
} 
  
  
  
  
 
  
  
  
  
public enum AType{ 
  
  
  
  
 
  
  
  
  
    P_T, 
  
  
  
  
 
  
  
  
  
    A_B 
  
  
  
  
 
  
  
  
  
} 
 
 
 
 

然后B系統(tǒng)依賴了這個(gè)二方庫(kù)，并且會(huì)通過(guò)RPC遠(yuǎn)程調(diào)用的方式調(diào)用AFacadeService的doSth方法。

 
 
 
 

  
  
  
  
public class BService { 
  
  
  
  
 
  
  
  
  
    @Autowired 
  
  
  
  
 
  
  
  
  
    AFacadeService aFacadeService; 
  
  
  
  
 
  
  
  
  
    public void doSth(){ 
  
  
  
  
 
  
  
  
  
        ARequest aRequest = new ARequest(); 
  
  
  
  
 
  
  
  
  
        AResponse aResponse = aFacadeService.doSth(aRequest); 
  
  
  
  
 
  
  
  
  
        AType aType = aResponse.getAType(); 
  
  
  
  
 
  
  
  
  
    } 
  
  
  
  
 
  
  
  
  
} 
 
 
 
 

這時(shí)候，如果A和B系統(tǒng)依賴的都是同一個(gè)二方庫(kù)的話，兩者使用到的枚舉AType會(huì)是同一個(gè)類，里面的枚舉項(xiàng)也都是一致的，這種情況不會(huì)有什么問(wèn)題。

但是，如果有一天，這個(gè)二方庫(kù)做了升級(jí)，在AType這個(gè)枚舉類中增加了一個(gè)新的枚舉項(xiàng)P_M，這時(shí)候只有系統(tǒng)A做了升級(jí)，但是系統(tǒng)B并沒(méi)有做升級(jí)。

那么A系統(tǒng)依賴的的AType就是這樣的：

 
 
 
 

  
  
  
  
public enum AType{ 
  
  
  
  
 
  
  
  
  
    P_T, 
  
  
  
  
 
  
  
  
  
    A_B, 
  
  
  
  
 
  
  
  
  
    P_M 
  
  
  
  
 
  
  
  
  
} 
 
 
 
 

而B(niǎo)系統(tǒng)依賴的AType則是這樣的：

 
 
 
 

  
  
  
  
public enum AType{ 
  
  
  
  
 
  
  
  
  
    P_T, 
  
  
  
  
 
  
  
  
  
    A_B 
  
  
  
  
 
  
  
  
  
} 
 
 
 
 

這種情況下，在B系統(tǒng)通過(guò)RPC調(diào)用A系統(tǒng)的時(shí)候，如果A系統(tǒng)返回的AResponse中的aType的類型為新增的P_M時(shí)候，B系統(tǒng)就會(huì)無(wú)法解析。一般在這種時(shí)候，RPC框架就會(huì)發(fā)生反序列化異常。導(dǎo)致程序被中斷。

原理分析

這個(gè)問(wèn)題的現(xiàn)象我們分析清楚了，那么再來(lái)看下原理是怎樣的，為什么出現(xiàn)這樣的異常呢。

其實(shí)這個(gè)原理也不難，這類RPC框架大多數(shù)會(huì)采用JSON的格式進(jìn)行數(shù)據(jù)傳輸，也就是客戶端會(huì)將返回值序列化成JSON字符串，而服務(wù)端會(huì)再將JSON字符串反序列化成一個(gè)Java對(duì)象。

而JSON在反序列化的過(guò)程中，對(duì)于一個(gè)枚舉類型，會(huì)嘗試調(diào)用對(duì)應(yīng)的枚舉類的valueOf方法來(lái)獲取到對(duì)應(yīng)的枚舉。

而我們查看枚舉類的valueOf方法的實(shí)現(xiàn)時(shí)，就可以發(fā)現(xiàn)，如果從枚舉類中找不到對(duì)應(yīng)的枚舉項(xiàng)的時(shí)候，就會(huì)拋出IllegalArgumentException：

 
 
 
 

  
  
  
  
public static > T valueOf(Class enumType, String name) { 
  
  
  
  
 
  
  
  
  
    T result = enumType.enumConstantDirectory().get(name); 
  
  
  
  
 
  
  
  
  
    if (result != null) 
  
  
  
  
 
  
  
  
  
        return result; 
  
  
  
  
 
  
  
  
  
    if (name == null) 
  
  
  
  
 
  
  
  
  
        throw new NullPointerException("Name is null"); 
  
  
  
  
 
  
  
  
  
    throw new IllegalArgumentException( 
  
  
  
  
 
  
  
  
  
        "No enum constant " + enumType.getCanonicalName() + "." + name); 
  
  
  
  
 
  
  
  
  
} 
 
 
 
 

關(guān)于這個(gè)問(wèn)題，其實(shí)在《阿里巴巴Java開(kāi)發(fā)手冊(cè)》中也有類似的約定：

這里面規(guī)定"對(duì)于二方庫(kù)的參數(shù)可以使用枚舉，但是返回值不允許使用枚舉"。這背后的思考就是本文上面提到的內(nèi)容。

擴(kuò)展思考

為什么參數(shù)中可以有枚舉?

不知道大家有沒(méi)有想過(guò)這個(gè)問(wèn)題，其實(shí)這個(gè)就和二方庫(kù)的職責(zé)有點(diǎn)關(guān)系了。

一般情況下，A系統(tǒng)想要提供一個(gè)遠(yuǎn)程接口給別人調(diào)用的時(shí)候，就會(huì)定義一個(gè)二方庫(kù)，告訴其調(diào)用方如何構(gòu)造參數(shù)，調(diào)用哪個(gè)接口。

而這個(gè)二方庫(kù)的調(diào)用方會(huì)根據(jù)其中定義的內(nèi)容來(lái)進(jìn)行調(diào)用。而參數(shù)的構(gòu)造過(guò)程是由B系統(tǒng)完成的，如果B系統(tǒng)使用到的是一個(gè)舊的二方庫(kù)，使用到的枚舉自然是已有的一些，新增的就不會(huì)被用到，所以這樣也不會(huì)出現(xiàn)問(wèn)題。

比如前面的例子，B系統(tǒng)在調(diào)用A系統(tǒng)的時(shí)候，構(gòu)造參數(shù)的時(shí)候使用到AType的時(shí)候就只有P_T和A_B兩個(gè)選項(xiàng)，雖然A系統(tǒng)已經(jīng)支持P_M了，但是B系統(tǒng)并沒(méi)有使用到。

如果B系統(tǒng)想要使用P_M，那么就需要對(duì)該二方庫(kù)進(jìn)行升級(jí)。

但是，返回值就不一樣了，返回值并不受客戶端控制，服務(wù)端返回什么內(nèi)容是根據(jù)他自己依賴的二方庫(kù)決定的。

但是，其實(shí)相比較于手冊(cè)中的規(guī)定，我更加傾向于，在RPC的接口中入?yún)⒑统鰠⒍疾灰褂妹杜e。

一般，我們要使用枚舉都是有幾個(gè)考慮：

• 1、枚舉嚴(yán)格控制下游系統(tǒng)的傳入內(nèi)容，避免非法字符。
• 2、方便下游系統(tǒng)知道都可以傳哪些值，不容易出錯(cuò)。

不可否認(rèn)，使用枚舉確實(shí)有一些好處，但是我不建議使用主要有以下原因：

• 1、如果二方庫(kù)升級(jí)，并且刪除了一個(gè)枚舉中的部分枚舉項(xiàng)，那么入?yún)⒅惺褂妹杜e也會(huì)出現(xiàn)問(wèn)題，調(diào)用方將無(wú)法識(shí)別該枚舉項(xiàng)。
• 2、有的時(shí)候，上下游系統(tǒng)有多個(gè)，如C系統(tǒng)通過(guò)B系統(tǒng)間接調(diào)用A系統(tǒng)，A系統(tǒng)的參數(shù)是由C系統(tǒng)傳過(guò)來(lái)的，B系統(tǒng)只是做了一個(gè)參數(shù)的轉(zhuǎn)換與組裝。這種情況下，一旦A系統(tǒng)的二方庫(kù)升級(jí)，那么B和C都要同時(shí)升級(jí)，任何一個(gè)不升級(jí)都將無(wú)法兼容。

我其實(shí)建議大家在接口中使用字符串代替枚舉，相比較于枚舉這種強(qiáng)類型，字符串算是一種弱類型。

如果使用字符串代替RPC接口中的枚舉，那么就可以避免上面我們提到的兩個(gè)問(wèn)題，上游系統(tǒng)只需要傳遞字符串就行了，而具體的值的合法性，只需要在A系統(tǒng)內(nèi)自己進(jìn)行校驗(yàn)就可以了。

為了方便調(diào)用者使用，可以使用javadoc的@see注解表明這個(gè)字符串字段的取值從那個(gè)枚舉中獲取。

 
 
 
 

  
  
  
  
public Class AResponse{ 
  
  
  
  
 
  
  
  
  
    private Boolean success; 
  
  
  
  
 
  
  
  
  
    /** 
  
  
  
  
 
  
  
  
  
    *  @see AType  
  
  
  
  
 
  
  
  
  
    */ 
  
  
  
  
 
  
  
  
  
    private String aType; 
  
  
  
  
 
  
  
  
  
} 
 
 
 
 

對(duì)于像阿里這種比較龐大的互聯(lián)網(wǎng)公司，隨便提供出去的一個(gè)接口，可能有上百個(gè)調(diào)用方，而接口升級(jí)也是常態(tài)，我們根本做不到每次二方庫(kù)升級(jí)之后要求所有調(diào)用者跟著一起升級(jí)，這是完全不現(xiàn)實(shí)的，并且對(duì)于有些調(diào)用者來(lái)說(shuō)，他用不到新特性，完全沒(méi)必要做升級(jí)。

還有一種看起來(lái)比較特殊，但是實(shí)際上比較常見(jiàn)的情況，就是有的時(shí)候一個(gè)接口的聲明在A包中，而一些枚舉常量定義在B包中，比較常見(jiàn)的就是阿里的交易相關(guān)的信息，訂單分很多層次，每次引入一個(gè)包的同時(shí)都需要引入幾十個(gè)包。

對(duì)于調(diào)用者來(lái)說(shuō)，我肯定是不希望我的系統(tǒng)引入太多的依賴的，一方面依賴多了會(huì)導(dǎo)致應(yīng)用的編譯過(guò)程很慢，并且很容易出現(xiàn)依賴沖突問(wèn)題。

所以，在調(diào)用下游接口的時(shí)候，如果參數(shù)中字段的類型是枚舉的話，那我沒(méi)辦法，必須得依賴他的二方庫(kù)。但是如果不是枚舉，只是一個(gè)字符串，那我就可以選擇不依賴。

所以，我們?cè)诙x接口的時(shí)候，會(huì)盡量避免使用枚舉這種強(qiáng)類型。規(guī)范中規(guī)定在返回值中不允許使用，而我自己要求更高，就是即使在接口的入?yún)⒅形乙埠苌偈褂谩?/p>

最后，我只是不建議在對(duì)外提供的接口的出入?yún)⒅惺褂妹杜e，并不是說(shuō)徹底不要用枚舉，我之前很多文章也提到過(guò)，枚舉有很多好處，我在代碼中也經(jīng)常使用。所以，切不可因噎廢食。

當(dāng)然，文中的觀點(diǎn)僅代表我個(gè)人，具體是是不是適用其他人，其他場(chǎng)景或者其他公司的實(shí)踐，需要讀者們自行分辨下，建議大家在使用的時(shí)候可以多思考一下。

【本文是專欄作者Hollis的原創(chuàng)文章，作者微信公眾號(hào)Hollis(ID：hollischuang)】

分享標(biāo)題：求你了，不要再在對(duì)外接口中使用枚舉類型了！
文章來(lái)源：http://www.5511xx.com/article/dpddeog.html