XamlSchemaContext.GetXamlType((Type)null) throws NRE

[hughbe]

This doesn't match the docs: https://docs.microsoft.com/en-us/dotnet/api/system.xaml.xamlschemacontext.getxamltype?view=netframework-4.7.2#System_Xaml_XamlSchemaContext_GetXamlType_System_Type_

Example test:

[Fact]
public void GetXamlType_NullXamlType_ThrowsNullReferenceException()
{
    var context = new XamlSchemaContext();
    Assert.Throws<NullReferenceException>(() => context.GetXamlType((Type)null));
}

Problematic code:

public virtual XamlType GetXamlType(Type type)
{
    return GetXamlType(type, XamlLanguage.TypeAlias(type)); // <-- NRE thrown in TypeAlias
}

internal XamlType GetXamlType(Type type, string alias)
{
    if (type == null)
    {
        throw new ArgumentNullException(nameof(type));
    }
    XamlType xamlType = null;
    if (!MasterTypeList.TryGetValue(type, out xamlType))
    {
        xamlType = new XamlType(alias, type, this, null, null);
        xamlType = TryAdd(MasterTypeList, type, xamlType);
    }
    return xamlType;
}

Should the code be updated, or the docs? I can fix the code if requested!

[stevenbrix]

I think the documentation makes sense and this should throw an ArgumentNullException.

If you don't already have a PR out for this, then let's hold off on doing so right now. While it may sound like we are being overly cautious (and maybe we are), simple innocent fixes like this can cause unforeseen compat issues. Imagine someone has the code like this:

void SomeMethod(XamlType type)
{
   XamlType xamlType = null;
   try
   {
       var context = new XamlSchemaContext();
        xamlType =  context.GetXamlType(type);
   }
   catch (System.NullReferenceException e)
   {
       // ...
   }
}

They will now be broken by changing the type of exception thrown. Even worse, maybe they caught both NullReferenceException and ArgumentNullException and did different things based on the exception type. Now we'd be causing the app's behavior to change.

These are the sort of things that have made compat issues very challenging in the .NET Framework. But now the side-by-side nature of .NET Core will allow us to easily make these sorts of changes in the future without any fear. However, we really want to ensure that everyone's experience porting their existing WPF applications from .NET Framework to .NET Core is as easy and seameless as possible. This means that we (the entire WPF community) should focus on minimizing possible compat issues as much as possible. Things start to get very complicated when we need to decide which simple fixes we deem as being "ok" and which ones aren't, and at many times the decisions will seem completely arbitrary. We will for sure take contributions if the issue is a clear regression from .NET Framework, and as we open-source more of the code there should be opportunities for the entire community to contribute to fixing some of those.

[vatsan-madhavan]

I think updating the docs might be the way to go here. I'm not sure that we'll ever be able to break this behavior - esp. since compatibility with existing codebases is an important tenet for us.

@mairaw, do you have suggestions on how to get the corresponding docs fixed?