錯(cuò)誤現(xiàn)象

確認(rèn)SQL沒有任何問題，但是在執(zhí)行時(shí)仍然出現(xiàn)以下報(bào)錯(cuò)，報(bào)錯(cuò)下標(biāo)越界：IndexOutOfBoundsException: Index 9 out of bounds for length 9

18:02:19.449 [http-nio-8007-exec-10] DEBUG c.t.c.c.d.GyUserWithdrawDao.listWihdraw - ==>  Preparing: SELECT gyw.*, ui.realname realname FROM `gy_user_withdraw` gyw inner join user_info ui on gyw.user_id = ui.userid LIMIT ? 
18:02:19.450 [http-nio-8007-exec-10] DEBUG c.t.c.c.d.GyUserWithdrawDao.listWihdraw - ==> Parameters: 10(Integer)
18:02:19.466 [http-nio-8007-exec-10] ERROR c.t.c.exception.ExceptionHandlerAdvice - 運(yùn)行異常
org.mybatis.spring.MyBatisSystemException: nested exception is org.apache.ibatis.exceptions.PersistenceException: 
### Error querying database.  Cause: java.lang.IndexOutOfBoundsException: Index 9 out of bounds for length 9
### The error may exist in file [D:\CIMS\gyyh_2.3.3\cims_commons_db\target\classes\mybatis\mysql\GyUserWithdrawMapper.xml]
### The error may involve com.trusfort.cims.commons.dao.GyUserWithdrawDao.listWihdraw
### The error occurred while handling results
### SQL: SELECT gyw.*, ui.realname realname FROM `gy_user_withdraw` gyw inner join user_info ui on gyw.user_id = ui.userid LIMIT ?
### Cause: java.lang.IndexOutOfBoundsException: Index 9 out of bounds for length 9
    at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:92)
    at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:440)
    at com.sun.proxy.$Proxy172.selectList(Unknown Source)
    at org.mybatis.spring.SqlSessionTemplate.selectList(SqlSessionTemplate.java:223)
    at org.apache.ibatis.binding.MapperMethod.executeForMany(MapperMethod.java:147)
    at org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:80)
    at org.apache.ibatis.binding.MapperProxy$PlainMethodInvoker.invoke(MapperProxy.java:144)
    at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:85)
    at com.sun.proxy.$Proxy369.listWihdraw(Unknown Source)

錯(cuò)誤原因

很明顯不是SQL的問題，從日志來看SQL明顯沒有問題，而且我們的Mapper.xml中配置也沒有問題

<select id="listWihdraw" resultType="GyUserWithdraw">
    SELECT gyw.*, ui.realname realname FROM `gy_user_withdraw` gyw inner join user_info ui on gyw.user_id = ui.userid
</select>

那就只能從Mybatis執(zhí)行SQL后查詢結(jié)果到實(shí)體映射的角度出發(fā)來考慮了。

我們看一下我們的實(shí)體類源碼

@Data
@Builder(toBuilder = true)
public class GyUserWithdraw implements Serializable {
    private String id;
    private String userId;
    private String employeenum;
    private String statusBefore;
    private String statusAfter;
    private String syncResult;
    private Date createTime;
    private Date updateTime;
}

看著貌似是沒什么毛病，但鑒于我們此處偷懶使用了Lombok的插件，還是仔細(xì)考慮回想一下

我們一般寫數(shù)據(jù)庫實(shí)體類的時(shí)候，只要有字段定義和對應(yīng)的getter、setter方法就可以了

為何用了Lombok的@Data注解之后有問題了呢？

我們看一下編譯后的實(shí)體類，用IDEA查看一下class反編譯的結(jié)果

重點(diǎn)來了

我們會發(fā)現(xiàn)與原本不使用Lombok的實(shí)體類相比，該類只有一個(gè)全參數(shù)的構(gòu)造方法，而原本我們手寫實(shí)體類時(shí)只寫了getter和setter方法，所以編譯后會默認(rèn)帶一個(gè)無參構(gòu)造。

而上述使用Lombok的@Builder注解后，編譯后實(shí)體有全參數(shù)的構(gòu)造方法，那么編譯器就不會再默認(rèn)提供一個(gè)默認(rèn)的無參構(gòu)造。

所以問題可能就出現(xiàn)在這個(gè)無參構(gòu)造方法缺失上，mybatis在將查詢結(jié)果映射成實(shí)體時(shí)是通過無參構(gòu)造獲得一個(gè)實(shí)例，然后調(diào)用setter方法將值存入相應(yīng)字段的。

解決方案

我們可以使用Lombok注解@NoArgsConstructor和@AllArgsConstructor，使編譯器編譯的時(shí)候提供出無參構(gòu)造。

在原實(shí)體上增加兩個(gè)注解即可，我們再重試就會發(fā)現(xiàn)SQL執(zhí)行正常了。

@Data
@Builder(toBuilder = true)
@NoArgsConstructor
@AllArgsConstructor

注意：

因?yàn)槲覀兪褂?code>@Builder注解，所以光添加一個(gè)@NoArgsConstructor,程序會編譯報(bào)錯(cuò)的，builder需要一個(gè)全參構(gòu)造，所以我們還得加上@AllArgsConstructor。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評論