Guard code in api stub methods

[nr-ahemsath]

Description

A customer reported exceptions being thrown from one of our API methods when called without the agent attached (meaning that the stub methods in NewRelic.cs were being executed, rather than the "real" API methods that the stubs get rewritten to when the agent is attached). This PR attempts to guard against any potential exceptions in two ways:

Add try/catch blocks around System.Diagnostics.Trace.WriteLine calls to prevent any exceptions thrown from use of this method from affecting a customer app.

Put nameof() around parameters passed to string.format to prevent any issues that might arise from trying to .ToString() objects passed in by users.

Testing

Unit tests pass. Did a quick smoke test of an app which used the API without the agent attached and it behaved as expected.

Changelog

Changelog updated

[lspangler584]

So if params are nullable, the compiler doesn't require they be referenced? If that's the case, it looks like SetApplicationName needs a reference to at least the first param.

[alanwest]

We should do nameof(paramName) on all params of all methods regardless of whether they are nullable.

[alanwest]

Suggested change

	try
	{
	System.Diagnostics.Trace.WriteLine(string.Format("NewRelic.RecordCustomEvent({0},{1})", nameof(eventType), nameof(attributes)));
	}
	catch
	{
	// Swallow any exception thrown from here
	}
	System.Diagnostics.Trace.WriteLine(string.Format("NewRelic.RecordCustomEvent({0},{1})", nameof(eventType), nameof(attributes)));

[alanwest]

All the methods should be safe without the try/catch now that we're not attempting to ToString the parameters.

For example, this RecordCustomEvent method can be problematic if the underlying type's ToString method is not thread-safe when attributes.ToString() is called. The type would be something like:

class MyEnumerable : IEnumerable<KeyValuePair<string, object>>
{
    // Performs work that is not thread-safe
    public override string ToString() ...
}

Dictionary<string, object> is such a type. https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic.dictionary-2. However, it's ToString method is likely safe, so it would likely have to be some custom type.

[nr-ahemsath]

I don't think we positively established that the reason the customer (or any customer in general) might experience an exception from these tracing calls can only be a non-threadsafe .ToString(). I'd prefer the belt-and-suspenders approach for maximum safety.

[lspangler584]

After discussion, decided to leave in try/catch since we are not certain the customer exception issue is resolved, and try/catch would guard against any future issues.