Should implicit operators handle null?
Should implicit operators handle null?
We've got a type which has an implicit string operator. It looks like this:
public class Foo
readonly string _value;
Foo(string value)
_value = value;
public static implicit operator string(Foo foo)
return foo._value;
public static implicit operator Foo(string fooAsText)
return new Foo(fooAsText);
We've just had a scenario where the instance passed to the implicit operator was null. Obviously, we ended up with a NullReferenceException.
null
NullReferenceException
I thought this was fair enough, after all, what IS the string representation of a type that is null - hard to say - so the exception seemed valid and something we shouldn't intercept/suppress/handle/ignore. My reasoning was along the lines of 'someone's given me a null, why should I return null. I don't do this in other methods'. I thought, 'I know, I'll just check for null before converting it', something like:
string s = foo == null ? null : foo;
string s = foo == null ? null : foo;
But that didn't work, because it's now converting to a string before the comparison to null. Of course, this comparison would work:
Foo f = null;
string s;
if (f != null)
s = f;
... but that's just ugly.
I read the section in Essential C# 5 4th edition (a 'Rough Cuts' book on Safari) and it says:
DO NOT throw exceptions from implicit conversions.
This says don't throw exceptions, but it leaves me wondering should I suppress exceptions?
The most obvious thing to do is to jump into the method and change it to:
public static implicit operator string(Foo foo)
return foo == null ? null : foo._value;
Problem solved. But I feel like dirty. I feel like I'm hiding a potential bug by checking for null. Am I being paranoid/anal/stupid?
string
Good point. Ideally we'd like never to come across a null instance of a
Foo. Hmmm... Perhaps it should be a struct...– Steve Dunn
Nov 29 '12 at 14:34
Foo
@SteveDunn: One important thing: A
NullReferenceException always indicates a bug in the code that raises the exception, not in calling the code. So simply not checking foo for null is a bug in the operator.– Daniel Hilgarth
Nov 29 '12 at 14:42
NullReferenceException
foo
null
2 Answers
2
What I would recommend in this case is that the operator which can fail should be explicit rather than implicit. The idea of an implicit conversion is that it is widening (i.e. it will never fail.) Explicit conversions, on the other hand, are understood to sometimes be able to fail.
That's what the documentation recommends, too: msdn.microsoft.com/en-us/library/z5z9kes2.aspx
– Jim Mischel
Nov 29 '12 at 14:43
You are trying to cast null to the type Foo as the type of both side of : must be equal.
:
string s = foo == null ? null : foo;
So you should use
string s = foo == null ? (string)null : foo;
or
string s = foo == null ? null : (string)foo;
Thanks for contributing an answer to Stack Overflow!
But avoid …
To learn more, see our tips on writing great answers.
Required, but never shown
Required, but never shown
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.
it all depends on your use case. do you want the
stringto be null?– Daniel A. White
Nov 29 '12 at 14:31