Why Convert.ToInt32(null) returns 0 in c#

Question

I just came across this today, if you convert null to int32

Convert.ToInt32(null) 

it returns 0

I was expecting an InvalidCastException...

Any idea why this happen?

Answer 1

Any idea why this happen?

Because that's the documented behaviour? Whether it's Convert.ToInt32(object) or Convert.ToInt32(string), the documentation states quite clearly:

(Under return value)

A 32-bit signed integer that is equivalent to the number in value, or 0 (zero) if value is null.

or

A 32-bit signed integer equivalent to value, or zero if value is null.

As always, if reality doesn't match expectations, the first thing you should do is check whether your expectations match the documented behaviour.

Personally I don't fully buy the "compatibility with VB6" argument shown by Gavin. I realize it comes from Microsoft, and it may well be the genuine reason why it behaves that way - but I don't think it's a good reason to behave that way. There are plenty of VB-specific conversion methods - so if the framework designers genuinely thought that returning zero was a non-ideal result, they should have done whatever they thought best, and provided a VB6 compatible conversion for use by VB6 programmers.

Obviously once the behavior was defined in .NET 1.0, it couldn't be changed for later versions - but that's not the same as saying it had to behave the same way as VB6.

Answer 2

See http://msdn.microsoft.com/en-us/library/sf1aw27b.aspx

Edit

The URL above automatically reverts to the latest Framework version, where as the text below was specifically posted on version 4. See the revised URL below which shows the text.

http://msdn.microsoft.com/en-us/library/sf1aw27b(v=vs.100).aspx

It explains:

All of the string-to-numeric conversion methods in the Convert class return zero if the string is null. The original motivation for this behavior was that they would provide a set of conversion methods for programmers migrating from Visual Basic 6 to Visual Basic .NET that mirrored the behavior of the existing Visual Basic 6 conversion methods. The assumption was that C# programmers would be more comfortable with casting operators, whereas Visual Basic had traditionally used conversion methods for type conversion.

Traditionally, the .NET Framework has tried to maintain a high degree of compatibility from version to version. Effectively, this means that, absent an extremely compelling reason, once a method has been implemented in a particular way and that implementation is publicly exposed (as in a method returning 0 if the string parameter is null), it cannot be changed, since that would break code that depends on the established behavior. This makes both of your proposed solutions very problemmatic. In the first case, throwing an exception changes the implementation of a method for customers who are likely to depend on the method returning zero for a null string. In the second case, it is important to remember that the .NET Framework does not consider return type in overload resolution. This means that your method would have to replace the existing Convert.ToInt32(String value) method, and that all code that does not expect to handle a nullable type would now be broken.

This concern for compatibility is even stronger in the case of the string-to-numeric conversion methods in the Convert class, since Parse is the recommended method for performing string-to-numeric conversion for each of the primitive numeric types supported by the .NET Framework, and each Parse method behaves differently that its corresponding Convert method. Unlike the string-to-numeric conversion method in the Convert class, which return zero if the string to be converted is null, each Parse method throws an ArgumentNullException, which is the behavior that you are arguing for. The overloads of the numeric Parse methods, such as Int32.Parse and Double.Parse, also have the advantage of allowing much finer-grained control over the parsing operation.