Java踩坑日志—220227

日常开发中，难免会修改代码的一些逻辑或处理。当修改的代码位于项目底层并对外提供二方包服务时，引用该二方包的项目所对应的版本是否同步修改升级，这取决于交互是否有变动：

第一种情况，只修改了业务处理的逻辑，并不涉及请求和响应的变动，此时不需要升级，只需将新的逻辑代码提交发布运行起来即可。第二种情况是修改了交互，此时必须得升级依赖版本并更新到依赖此底层服务的上层项目上。

        
            com.drewnoakes
            metadata-extractor
            2.13.0
        

因为服务器一般是分布式多服务的，当更新系统时，有一种情况是旧的交互方式请求转发到新的交互方式刚重启的系统服务器上时，因交互的格式变更，此时会发生包括序列化在内的一系列错误，严重的会导致线上事故。

日常开发中，会遇到这样一种情况，当方法里引用了二方包里的服务时，该服务可能会要求方法声明抛出某种异常，此时若按照要求声明此异常，那么调用该方法的上游方法将全部声明该异常或该异常的父类，这是一种很不够优雅的方式。

@Override
    public void updateMyPassword(String password, String oldPassword) throws ServiceException {

        if (StringUtils.validateStrongPassword(password) == null) {
            throw new ServiceException(ERR_PASSWORD_VALID_DENIED);
        }

        Artisan artisan = findById(ArtisanContexts.requestArtisanId());

        if (!artisan.getPassword().equals(StringUtils.encryptPassword(oldPassword, artisanConfig.getSalt()))) {
            throw new ServiceException(ERR_PASSWORD_INVALID);
        }

        artisan.setPassword(StringUtils.encryptPassword(password, artisanConfig.getSalt()));

        artisanRepository.save(artisan);
    }

发生这种情况的原因是引入的服务所抛出的异常并不是继承自运行时异常RuntimeException，因为继承运行时异常的异常即使不在方法体上声明，在方法运行时若抛出了该异常也会被自动捕捉。所以想要避免这种情况，可以在方法体里通过try...catch...finally结构捕捉该异常，并在catch语句中转换为RuntimeException或是继承了RuntimeException的自定义异常，此时不必声明也可自动捕捉。

public Artisan findById(Long artId) {
        try {
            Artisan artisan = artisanRepository.findById(artId).orElse(null);
            return artisan;
        } catch (Exception e) {
            throw new RuntimeException("发生了异常");
        }
    }

在调用第三方服务接口时，我们要先初始化实例其实现类才能正常使用，可以把实例化的定义成一个注解，当有需要时添加该注解即可。当然简单的一点的就是通过配置文件去实例化了。