`Task<T>` debug proxy is misleading about `Result` of a non-success task

[DoctorKrolic]

Description

System.Threading.Task<T> has a custom debug proxy. This debug proxy returns default value of T instead of indicating a potential exception for a Result property of a faulted task

Reproduction Steps

var mt = M();
await ((Task)mt).ConfigureAwait(ConfigureAwaitOptions.SuppressThrowing);

Console.WriteLine(mt.Result);

async Task<string> M()
{
    throw new NotImplementedException();
}

• Break point on Console... line.
• Start debugging
• Reach the break point and inspect Result property

Expected behavior

Debug proxy indicates that accessing Result will throw an exception

Actual behavior

Result shows default value (in this case null), misleading developers about actual property behavior:

Regression?

No

Known Workarounds

No response

Configuration

No response

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-threading-tasks
See info in area-owners.md if you want to be subscribed.

[stephentoub]

Debug proxy indicates that accessing Result will throw an exception

It shows that the task is in a Faulted state and that there's an exception. Wait, Result, etc will all throw in that state.

[DoctorKrolic]

Wait, Result, etc will all throw in that state.

It may be obvious to someone, who heavily worked with (if not designed) Tasks in the past, but it may mislead devs who don't use raw Task frequenly. This issue is a result of me pattern matching a task like { Result: { } resultObj } thinking this will match a successful task and extract its result at the same time just to later be extreamly confused debugging a faulted case, when I clearly see null in the debugger, but accessing the propery in code/expression evaluator fails. I even thought this might be a weird debugger bug for some time. So IMHO debugger proxies should not change such important behaviors of their underlying objects.