记一次线上问题排查:C#可选参数的坑

线上报了大量异常,错误信息为:找不到XX方法实现

记一次线上问题排查:C#可选参数的坑

 

代码调用关系是:

记一次线上问题排查:C#可选参数的坑

 

 

查看代码历史记录,发现最近上线前对 GetUserDottedLineSuperiors 方法做过修改,增加了一个可选参数。

记一次线上问题排查:C#可选参数的坑

 

 

跟相关开发同学确认后,是Hotfix的方式上线了UserService.dll,没有整版发布(而在测试环境验证的时候是整版发布)。

按说,改了哪里的代码,只需要更新该代码所在的dll即可,也就是只更新UserService.dll是没毛病的。

But,这样是不对的。

我们分别看一下DataRule.dll的源码和反编译后的代码:

记一次线上问题排查:C#可选参数的坑

 

 

 代码(上图)还是保持着增加可选参数之前的样子,因为有可选参数的存在,编译一点问题都没有。

记一次线上问题排查:C#可选参数的坑

 

然而,反编译后(上图),发现编译器给加了一个可选参数的默认值。

说明虽然DataRule项目里的代码虽然没动,但是编译后的dll其实是跟之前不一样了。因此需要更新这个DataRule.dll。

由此也可以窥视一下C#的可选参数的实现方式,实际是在调用点加上了参数的默认值。

--------------------------------------------------------------------------------------------------------------------------------

其实一开始我也好奇,因为看IL,确实是给可选参数增加了[OPT]的标签,按说应该起作用

记一次线上问题排查:C#可选参数的坑

 

 后面有时间再查一下MethodTable,我猜应该是MethodTable中此方法是3个参数,而且调用点应该也是去查MethodTable中三个参数对应的方法地址,因为调用的地方,IL是:

记一次线上问题排查:C#可选参数的坑

 

 确实是要跳到三个参数对应的方法地址

 

记一次线上问题排查:C#可选参数的坑

上一篇:C# 表达式树讲解(一)


下一篇:c#通过成员名字获取值