views:

2045

answers:

7

I have this extract of C# 2.0 source code

object valueFromDatabase;
decimal result;
valueFromDatabase = DBNull.Value;

result = (decimal)(valueFromDatabase != DBNull.Value ? valueFromDatabase : 0);
result = (valueFromDatabase != DBNull.Value ? (decimal)valueFromDatabase : (decimal)0);

The first result evaluation throws an invalid cast exception whereas the second one does not. What is the difference between these two?

+9  A: 

The difference is that the compiler can not determine a data type that is a good match between Object and Int32.

You can explicitly cast the int value to object to get the same data type in the second and third operand so that it compiles, but that of couse means that you are boxing and unboxing the value:

result = (decimal)(valueFromDatabase != DBNull.value ? valueFromDatabase : (object)0);

That will compile, but not run. You have to box a decimal value to unbox as a decimal value:

result = (decimal)(valueFromDatabase != DBNull.value ? valueFromDatabase : (object)0M);
Guffa
C# Specification:"A boxing conversion permits a value-type to be implicitly converted to a reference type. A boxing conversion exists from any non-nullable-value-type to object, to System.ValueType and to any interface-type implemented by the non-nullable-value-type. Furthermore an enum-type can be converted to the type System.Enum. "So there is implicit boxing conversion between Int32 and object.If the compiler could not determine the type it would fail at compile time and not at runtime.Please see my answer...
Dzmitry Huba
+3  A: 

The x : y part need a common type, the database's value is likely some kind of float and 0 is an int. This happens before the cast to decimal. Try ": 0.0" or ": 0D".

ongle
What the value from the database actually is has no relevance for the compiler. The type of the variable is Object, and a Double value will not match better than an Int32 value.
Guffa
As others have said, it is 0m
KClough
Literal zero of type decimal: 0m.
Richard
This is not a compiler error, it is a run time error. Databases normally return decimal values as doubles so that is the type you are trying to match.
ongle
However, if the runtime type is decimal then go ahead and use M. :)
ongle
@ongle: If a database returns a Decimal value as a Double it is a serious error, as you will lose precision.
Guffa
@Guffa: Decimal is the c# type, not the DB type. We don't know what the DB type is (Decimal in SQL Server means something else with a definable precision). The key here is that this is a run time error, what matters is the run time type of the value in valueFromDatabase. Whatever type that is is the type that needs to be matched or special casting should be employed to make the values type compatible (The solution your answer takes). I'm betting it is a double.
ongle
+5  A: 

The type of the operator will be object and in case the result must be 0 it will be implicitly boxed. But 0 literal is by default has int type so you box int. But with explicit cast to decimal you try to unbox it which is not permitted (boxed type must much with the one you cast back to). That is why you can get exception.

Here is an excerpt from C# Specification:

The second and third operands of the ?: operator control the type of the conditional expression. Let X and Y be the types of the second and third operands. Then,

  • If X and Y are the same type, then this is the type of the conditional expression.
  • Otherwise, if an implicit conversion (§6.1) exists from X to Y, but not from Y to X, then Y is the type of the conditional expression.
  • Otherwise, if an implicit conversion (§6.1) exists from Y to X, but not from X to Y, then X is the type of the conditional expression.
  • Otherwise, no expression type can be determined, and a compile-time error occurs.
Dzmitry Huba
+2  A: 

Unless I'm mistaken (which is very possible) its actually the 0 that's causing the exception, and this is down to .NET (crazily) assuming the type of a literal so you need to specify 0m rather than just 0.

See MSDN for more info.

Mark
A: 

There are two different types for the compiler to decide (at compile time) which one to cast to decimal. This it can't do.

Ioannis
+3  A: 

Your line should be:

result = valueFromDatabase != DBNull.value ? (decimal)valueFromDatabase : 0m;

0m is the decimal constant for zero

Both parts of a conditional operator should evaluate to the same data type

Philippe Leybaert
That will most likely compile into exactly the same code as the second line.
Guffa
maybe, but it's worth pointing out what the decimal constant for zero is
Philippe Leybaert
+68  A: 

UPDATE: This question was the subject of my blog on May 27th 2010. Thanks for the great question!

There are a great many very confusing answers here. Let me try to precisely answer your question. Let's simplify this down:

object value = whatever;
bool condition = something;
decimal result = (decimal)(condition ? value : 0);

How does the compiler interpret the last line? The problem faced by the compiler is that the type of the conditional expression must be consistent for both branches; the language rules do not allow you to return object on one branch and int on the other. The choices are object and int. Every int is convertible to object but not every object is convertible to int, so the compiler chooses object. Therefore this is the same as

decimal result = (decimal)(condition ? (object)value : (object)0);

Therefore the zero returned is a boxed int.

You then unbox the int to decimal. It is illegal to unbox a boxed int to decimal. For the reasons why, see my blog article on that subject:

http://blogs.msdn.com/ericlippert/archive/2009/03/19/representation-and-identity.aspx

Basically, your problem is that you're acting as though the cast to decimal were distributed, like this:

decimal result = condition ? (decimal)value : (decimal)0;

But as we've seen, that is not what

decimal result = (decimal)(condition ? value : 0);

means. That means "make both alternatives into objects and then unbox the resulting object".

Eric Lippert
+1 Nice explanation.
Andrew Hare
I don't understand why compiler is inserting type conversions where compilation error seems to be more appropriate.
raj
@raj: What rule would you like to see implemented to determine when to give a compilation error?
Eric Lippert
@Eric, I believe Compiler should have told me this rule "the language rules do not allow you to return object on one branch and int on the other" instead of casting int to object to make itself happy. Loannis would have found the problem with the statement had compiler told him what's wrong with it
raj
@Raj: OK, then what should the compiler do with b ? "" : null - that returns a string on one branch and a typeless null reference on the other. Should the compiler complain about that? Since one side doesn't even have a type, clearly the types are not equal.
Eric Lippert