【问题标题】:Arithmetic overflow exception in .net 2.0 and greater.net 2.0 及更高版本中的算术溢出异常
【发布时间】:2015-03-20 13:05:10
【问题描述】:

我收到了这个错误

System.OverflowException: Arithmetic operation resulted in an overflow.

当我在 .Net 2.0 或更高版本 (.Net 4.0) 中编译的 Windows Server 2008 R2 Standard 上运行我的应用程序时。据我所知,如果 C# 在没有 /checked 参数的情况下编译,则应该忽略算术溢出。在我的应用中有很多地方会发生溢出,所以我需要忽略它。

我追踪了一个例子:

using System;

namespace ArithmeticOverflow
{
    class Program
    {
        static void Main( string[] args )
        {
            GetTypeID( typeof( Program ) );
        }

        public static int GetTypeID( Type type )
        {
            return type.GetHashCode() ^ type.FullName.GetHashCode() ^ type.TypeHandle.Value.ToInt32();
        }
    }
}

使用 .net 2.0 编译:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc.exe /out:test.exe Program.cs

当我在台式计算机上运行此程序时,一切正常。但是当我在服务器上运行它时,它崩溃了。我找不到问题。

如果我用 .net 1.1 编译它:

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\csc.exe /out:test.exe Program.cs

在台式机和服务器上都可以。那么问题出在哪里?请帮忙。

更新

使用 /platform:anycpu32bitpreferred 解决

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\csc.exe /unsafe /platform:anycpu32bitpreferred /out:test.exe Program.cs

【问题讨论】:

  • 你想用逻辑或做什么?
  • @Gilad: ^ 是 XOR,而不是 OR。
  • @JonSkeet 是的,对不起我的错字。

标签: c# .net arithmetic-expressions


【解决方案1】:

我怀疑您会发现问题在于,在 .NET 1.1 中,您在两种情况下都运行 x86 CLR,而在 .NET 2.0 中,您可能在桌面上运行 x86,而在服务器上运行 x64。

IntPtr.ToInt32 是 documented 抛出 OverflowException 时:

在 64 位平台上,此实例的值太大或太小而无法表示为 32 位有符号整数。

基本上,这样称呼是很危险的。为什么不直接使用IntPtr.GetHashCode()? (老实说,目前还不清楚你到底想用这段代码实现什么。)

【讨论】:

  • 我的台式电脑是 Windows 7 Ultimate 64 位。所以它也应该崩溃,对吗?我的app是RunUO 1.1修改的,有很多地方会溢出,修复起来会很费时间。
  • @user1576055:您必须打印出System.Is64BitProcess 或类似的东西来验证正在使用哪个CLR。但是仅仅因为你在多个地方都有一个错误并不能使它成为一个更少的错误。请注意,这与 算术 溢出无关——它与这一特定方法有关。如果您在很多地方以相同的方式调用这个方法 (Int64.ToInt32),您可能需要考虑先将它们全部重构到一个地方...
  • 你说得对,谢谢。在我的桌面 PC Environment.Is64BitProcess 上是假的,但在服务器上是真的。如果问题仅出在 ToInt32() 方法中,我会尝试修复它,它应该不会太难。非常感谢。
  • @JonSkeet 我知道这有点离题了。已经有这样的问题:why dont languages raise errors on integer overflow by default。我没有看到任何专家对此的任何 cmets。所有答案都归结为-“是的,由于性能成本,默认情况下不启用它。但是检查的行为是用户几乎在大多数情况下都会期望的”话虽如此,所以应该从那个开始或不考虑性能影响?
  • @RahulAgarwal:正如你所说,这不是真正的话题 - Stack Overflow 上的 cmets 不适合这样的讨论。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-06-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多