I noticed that we had repeated code for handling what happens when ChangeType returns TypeConversion.NoMatch. We are mostly throwing (variations) of NewExpressionBuildingException, so I refactored a bit to make ChangeType throw a consistent error, using the throwOnError techique that we used elsewhere.
Then, I noticed this code:
// If we make this a hard fail, 15 unit tests fail.
// throw this.NewExpressionBuildingException(
// $"Cannot convert {expression.Type.ToCSharpString(Defaults.TypeCSharpFormat)} to {tsType.ToCSharpString(Defaults.TypeCSharpFormat)}");
So, we actually had 15 unit tests failing, but their failure was turned into a line in a log file. Sure enough, when I uncommented this, I got 15 (well, really 16) unit tests failing.
I was able to fix 14 out of sixteen (but see #543) cases, which left two, which are covered under #519 and #543. For now, I have suppressed these last two again.
Fix for
583
I noticed that we had repeated code for handling what happens when
ChangeType
returnsTypeConversion.NoMatch
. We are mostly throwing (variations) ofNewExpressionBuildingException
, so I refactored a bit to makeChangeType
throw a consistent error, using thethrowOnError
techique that we used elsewhere.Then, I noticed this code:
So, we actually had 15 unit tests failing, but their failure was turned into a line in a log file. Sure enough, when I uncommented this, I got 15 (well, really 16) unit tests failing.
I was able to fix 14 out of sixteen (but see #543) cases, which left two, which are covered under #519 and #543. For now, I have suppressed these last two again.