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年就达到了,是否说明在架构设计时就考虑不周,有严重缺陷呢?

相关推荐
longlong int3 小时前
【每日算法】Day 16-1:跳表(Skip List)——Redis有序集合的核心实现原理(C++手写实现)
数据库·c++·redis·算法·缓存
baobao17676408303 小时前
Mysql 数据库编程技术01
数据库·mysql·oracle
一 乐4 小时前
实验室预约|实验室预约小程序|基于Java+vue微信小程序的实验室预约管理系统设计与实现(源码+数据库+文档)
java·数据库·微信小程序·小程序·毕业设计·论文·实验室预约小程序
极限实验室4 小时前
INFINI Labs 产品更新 | Coco AI 0.3 发布 – 新增支持 Widget 外部站点集成
数据库·搜索引擎
我科绝伦(Huanhuan Zhou)4 小时前
MySQL数据库如何在线修改表结构及字段类型?
数据库·mysql
独行soc4 小时前
2025年渗透测试面试题总结- 某四字大厂面试复盘扩展 一面(题目+回答)
java·数据库·python·安全·面试·职场和发展·汽车
hez20104 小时前
用 .NET NativeAOT 构建完全 distroless 的静态链接应用
c#·.net·aot·.net core·native
rockmelodies4 小时前
【MongoDB + 向量搜索引擎】MongoDB Atlas 向量搜索 提供全托管解决方案
数据库·mongodb·搜索引擎
西元.5 小时前
详解 Redis repl_backlog_buffer(如何判断增量同步)
数据库·redis·缓存
幻想趾于现实6 小时前
C# Winform 入门(11)之制作酷炫灯光效果
开发语言·c#·winform