You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
🚸UnitParser.Parse should throw AmbiguousUnitParseException before any UnitNotFoundException (#1484) (#1494)
Fixes#1423 for `release-v6`
Carry over from #1484
`UnitParser.Parse<LengthUnit>("MM")` fails due to matching both
`Megameter` and `Millimeter` in case-insensitive matching, but matches
neither of them in the case-sensitive fallback. It was confusing to get
`UnitsNotFoundException` in this case, since case-insensitive usually
works for most units.
### Changes
- Handle this case and throw `AmbiguousUnitParseException` instead of
`UnitNotFoundException`
- Describe the case-insensitive units that matched
- Fix existing test
`Parse_WithMultipleCaseInsensitiveMatchesButNoExactMatches_ThrowsUnitNotFoundException`
- Skip retrying with fallback culture if no specific `formatProvider`
was given
- Avoid some of the unnecessary array allocations
Co-authored-by: Andreas Gullberg Larsen <[email protected]>
thrownewAmbiguousUnitParseException($"Cannot parse \"{unitAbbreviation}\" since it matches multiple units: {unitsCsv}.");
92
92
}
93
93
}
94
94
}
@@ -216,21 +216,26 @@ public bool TryParse([NotNullWhen(true)] string? unitAbbreviation, Type unitType
216
216
// TODO see about optimizing this method: both Parse and TryParse only care about having one match (in case of a failure we could return the number of matches)
0 commit comments