C# Value was either too large or too small for an Int32

C#程序遇到报错:Value was either too large or too small for an Int32

这是个常见的数据类型转换报错,如果出现在程序开发过程中,这个问题很容易定位。但是在长期没有进行程序更新的生产环境中突然出现,排查思路就很重要,记录一下这个问题的排查过程吧。

一、概述

成产环境近期(约1个月)无程序更新的情况下大面积开始出现以上报错,多个业务逐步受到影响。起初看到异常,没有怀疑代码的问题,因为近期没有程序更新,所以主观上开始排查数据库中多个数据源新产生的异常数据,包括从视图、DBLinks获取的新数据。

二、排查数据库

先排查了最开始出现错误时刻的数据,发现了2种异常数据,还都是异常的日期。

但很快这方面的原因就排除了,有两点:1、日期字段中虽然数据异常,但是格式仍然正确(YYYY-MM-DD HH24:MI:SS)。2、程序内部对日期数据有toString()的处理,因此不可能出现上文中......too small for an Int32 和数字类型相关的报错。

三、排查代码

重新看下报错日志,根据代码行定位,找到了对应的方法,是一个对数据库表数据和实体类进行转换的方法。再仔细看看这个写法Int32.Parse(......),就应该意识到和Int32数据类型转换时,数据太大或太小从而导致溢出有关了。 将该数据的转换改为Int64.Parse,即可解决该问题。

在这里提一下int32这个数据类型,在C#中,int int32类型的数据范围是固定的,也就是 -2,147,483,6482,147,483,647,即 -2^31 2^31 - 1

int64、long、decimal......则可以表示更大的范围,以int64为例,可以表示 -2^63 ( -9,223,372,036,854,775,808) 2^63-1(+9,223,372,036,854,775,807 )。因此在程序设计时,变量的定义除了考虑性能,还应该充分考虑实际业务的增量。

四、重新排查数据来源,确定问题

根据业务很容易排查到源头,REC_ID来自业务表的主键。果然,查看了下MAX(REC_ID)已经超过了Int32的上限。Oracle中该字段使用了Number类型存储,远远超过Int32的上限,因此该数据在Oracle中无异常,但是在程序代码中就无法正常转换了。

总结:在程序设计时,变量的定义除了考虑性能,还应该充分考虑实际业务的增量,特别是作为主键的变量,20亿的增量4年就达到了,是否说明在架构设计时就考虑不周,有严重缺陷呢?

相关推荐
nomi-糯米5 分钟前
Mybatis-plus代码生成器的创建使用与详细解释
数据库·mysql·mybatis
涛思数据(TDengine)7 分钟前
时序数据库 TDengine × Perspective:你需要的可视化“加速器”
数据库·时序数据库·tdengine
傻小胖12 分钟前
MongoDB的下载安装与启动
数据库·mongodb
深鱼~1 小时前
【Redis】缓存|缓存的更新策略|内存淘汰策略|缓存预热、缓存穿透、缓存雪崩和缓存击穿
数据库·redis·缓存
nicepainkiller1 小时前
redis高阶2 高性能
数据库·redis·缓存
Algorithm15761 小时前
Redis的ZSet对象底层原理——跳表
数据库·redis·缓存
爱编程的鱼1 小时前
C# 继承详解
开发语言·c#
IT北辰1 小时前
Python数据处理:文件的自动化重命名与整合
数据库·python·自动化
神仙别闹1 小时前
基于C#窗体+GDI+绘图实现分形树
开发语言·c#
猫头虎2 小时前
数据库中DDL、DML、DCL的区别是什么?
数据库·数据仓库·sql·oracle·database·时序数据库·big data