BindConverter throws exception on parse failure
uecasm opened this issue · comments
Is there an existing issue for this?
- I have searched the existing issues
Describe the bug
When using an unsigned integer type with BindConverter (and perhaps other cases where it appears to internally fall back to a TypeConverter), parse failure can cause an exception to be thrown.
Expected Behavior
Given that the method name follows the Try* pattern and explicitly indicates that it is supposed to return false on parse failure, it should return false instead of throwing an exception.
On a related note, it would be nice if InputNumber supported binding directly to uint fields, which is not currently the case (though this throws a different error at binding time, irrespective of value).
Steps To Reproduce
try
{
var success = BindConverter.TryConvertTo<uint>("-42", CultureInfo.CurrentCulture, out _);
Console.WriteLine($"Expecting False, was: {success}");
}
catch (Exception ex)
{
Console.WriteLine($"Unexpected exception: {ex}");
}(This can be run from a plain console app that references <PackageReference Include="Microsoft.AspNetCore.Components" Version="6.0.6" />.)
Exceptions (if any)
Unexpected exception: System.ArgumentException: -42 is not a valid value for UInt32. (Parameter 'value')
---> System.OverflowException: Value was either too large or too small for a UInt32.
at System.Number.ThrowOverflowOrFormatException(ParsingStatus status, TypeCode type)
at System.UInt32.Parse(String s, NumberStyles style, IFormatProvider provider)
at System.ComponentModel.UInt32Converter.FromString(String value, NumberFormatInfo formatInfo)
at System.ComponentModel.BaseNumberConverter.ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, Object value)
--- End of inner exception stack trace ---
at System.ComponentModel.BaseNumberConverter.ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, Object value)
at Microsoft.AspNetCore.Components.BindConverter.ParserDelegateCache.<>c__DisplayClass6_0`1.<MakeTypeConverterConverter>g__ConvertWithTypeConverter|0(Object obj, CultureInfo culture, T& value)
at Microsoft.AspNetCore.Components.BindConverter.TryConvertTo[T](Object obj, CultureInfo culture, T& value)
at Program.<Main>$(String[] args) in D:\Drives\blazor\UnsignedBindConverter\Program.cs:line 6
.NET Version
6.0.300
Anything else?
.NET SDK (reflecting any global.json):
Version: 6.0.300
Commit: 8473146e7d
Runtime Environment:
OS Name: Windows
OS Version: 10.0.19041
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\6.0.300\
Host (useful for support):
Version: 6.0.5
Commit: 70ae3df4a6
.NET SDKs installed:
2.1.511 [C:\Program Files\dotnet\sdk]
6.0.200 [C:\Program Files\dotnet\sdk]
6.0.300 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.All 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
@uecasm thanks for contacting us.
this has come up in the past, I don’t remember what the decision was. That said, it sounds reasonable, but at the same time it does using an appropriate type that can represent the input values.
Thanks for contacting us.
We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
It's an easy fix; all that needs to happen is a try/catch wrapped around this line:
I just encountered a similar issue with TimeSpan. I'm on .NET 6. I don't expect this to throw an Exception:
TimeSpan result;
BindConverter.TryConvertTo<TimeSpan>("", CultureInfo.InvariantCulture, out result);
It results in an exception:
System.FormatException: String '' was not recognized as a valid TimeSpan
Please fix it
It results in an exception:
System.FormatException: String '' was not recognized as a valid TimeSpan
You should really be using TimeSpan? instead if you want to treat an empty string as valid input. Although it's true that it shouldn't be throwing when invalid.
Thanks for contacting us.
We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Thanks for contacting us.
We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Thanks for contacting us.
We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.