MS doing the wrong thing because of the wrong backwards compatibility reasons (TypeConverter.IsValid story)

About a year ago (feb-22-2005) I reported a bug in the implementation of most built-in TypeConverters, which is that even if the value you pass to IsValid is invalid for the target type, it will return true. To better understand the issue (which is fairly trivial anyway), say you have code like the following that performs validation on a property value before setting it:

object theObject;        // Received somehow
object theValue;         // Received somehow
PropertyInfo property;   // Get the property info using reflection for the property we're about to set.

TypeConverter converter = TypeDescriptor.GetConverter(property.PropertyType);
if (!converter.IsValid(theValue))
{
    throw new ArgumentException();
}
else
{
    property.SetValue(theObject, theValue, null);
}

Now, because of the bug I mentioned, the if will never enter as the built-in converters will always report a valid value even if you pass an "asdf" for an integer property, for example. So, obviously my code has a bug that I still didn't realize (assuming I didn't do any TDD, of course, as otherwise I'd already know there's no way that code would work as expected).

Someone on the .NET team decided that it was going to be a breaking change to fix it. In their words, two months after I reported the bug, they said:

"Since TypeConverters are used so widely, changing the Int32Converter (and the other TypeConverters mentioned) to override IsValid will likely break applications, ..."

Now, how can an application be broken if a piece of functionality is not usable because it never behaves as expected? Clearly the application is already broken (if it uses code like the one I showed above) and probably the developers didn't realize yet.

After I reopened the bug so that it gets considered for post-Whidbey, I got the following answer:

"We do not have the luxury of making that risky assumption that people will not be affected by the potential change."

And closed as won't fix. I think this is a clear case where the back-compat issue is taken too far and clearly hinders the usability and quality of the platform.

If you agree, go vote the bug. The .NET platform CAN be better.

12 Comments

  • Voted. That's perhaps the lamest bug resolution I've seen. I'd really like to see an example of working code they think would be broken by correcting this bug.

  • I suspect that the issue is more that broken code that has been fortuitously working up until this point might end up breaking as it actually should have in the first place. I agree that it should be fixed, but the problem that Microsoft faces is that the client may not have the source for the broken app. One possible solution is to use side-by-side execution features of the .NET Framework and insist that clients affected by this breaking change install the .NET Framework 1.1 so the application runs against the Framework version it was originally built with.

  • The decision Microsoft made IS NOT driven by their laziness, but on a bad design api.



    IsValid is a bad api, because it does not accept any kind of culture. And if you will not pass CultureInfo to IsValid method, the code will be broken on non-invariant cultures and it will be the huge problem.



    I think MS _IS_ right in this situation.



    If you really want IsValid functionaity, write your own IsValid method (that accepts culture) and use ConvertFromString in TypeConverter. In case FormatException in caught, return false, else - true.

  • I missed the part where it's wrong to assume the current culture if no one is provided... that works in the vast majority of cases...

  • There is no overload of IsValid method taking CultureInfo as a parameter. CurrentCulture is only a fallback scenario, not the main one. Every part of framework that deals with parsing/formatting can accept CultureInfo.

  • MS never made the point you're making. From their answers, the problem has nothing to do with cultureinfos.



    Now, even accepting your argument, you think their decision is better than adding a new virtual overload of IsValid that accepts the culture?? Because clearly that wouldn't be a breaking change and would leave you happy.



    I think they don't do it for other reasons, and that's the one they exposed: that fixing the broken IsValid is a breaking change that should never happen, even if that means that the framework will contain a method that is absolutely useless.

  • Daniel, MS sometimes does mistakes, but they are not completely lamers. If they don't want to fix this "obvious" bug, they have very, very strong reason not to do it.



    In WinFX wave, for example, they use exception handling to determine validness of specific values.

  • Lexp: looks like you work for them ;).

    If you go and review the reasons they gave, they are just not credible. They sometimes do that, believe me. As someone who has filed more than 120 bugs in productfeedback, I can tell you that sometimes they do fix things, or give sensible reasons when they don't. And some other times it just looks like a whim. Even though I try to understand the real reasons.



    So, I agree they are not completely lamers, not at all. But they are not all "very very strong" reasoners all the time, for all matters either.

  • Daniel, initially I was going to vote on your favor (and believe me, I'm not a "Microsoft believer"/"Microsoft is always right" kind of guy, but I think there's a somewhat valid reason that they refrain from stating explicitly:

    The problem is there may exist (deployed) applications that rely on the following code:

    if (!intConverter.IsValid("blah"))

    {

    throw new BlahException("weird, this never happened before...");

    }

    They fixing this bug would "break" these applications (note: not the code, but the application would start throwing this exception they didn't throw before).



    I agree this is rather exceptional since the IsValid invocation will usually preceed the actual use of the value which will throw an ArgumentException, but it might happen.



    I consider this such a marginal probability that I'm voting for it to be fixed anyways.

  • I added a comment as a workaround (FDBK21792#2: Change your reasoning), since comments have been disabled... for months now?



  • I agree with your comment. The possiblity of some actually having code that would break by the fix is ridiculous. If you're checking the validity of the value using a converter, at *some* point during the application you're using the value. I can't think of scenario where you would check for the validity, and save the value not to use it anymore *ever*.

  • Well, I just stumbled in that product feedback, and I was totally shocked by their answer.

    Needless to say I have voted for that bug.

    Please Daniel, meet them at the next msdn chat and tell them to reopen this for Orcas.

Comments have been disabled for this content.