Сообщение [Request] диагностика для return task внутри try...catch от 18.07.2018 13:50
Изменено 18.07.2018 14:57 Sinix
[Request] диагностика для return task внутри catch
Пример кода из реального проекта (упростил):
Сопротивление бесполезно, угу
Как насчёт диагностики "утекания" промайза из области, обёрнутой в try{...} / using{...} ?
Промайза — т.к. кроме собственно Task<> так же может выстрелить любой awaitable тип (ValueTask, Task.ConfigureAwait() etc).
Если совсем заморочиться, то можно попытаться то же самое добавить для ленивых enumerable, но для них будет слишком много ложных срабатываний.
public Task<Something> TryGetSomethingAsync(string arg)
{
try
{
return GetSomethingAsync(arg);
}
catch (SomeException ex) // Nope.
{
throw HandleException(ex, arg);
}
}Сопротивление бесполезно, угу
Как насчёт диагностики "утекания" промайза из области, обёрнутой в try{...} / using{...} ?
Промайза — т.к. кроме собственно Task<> так же может выстрелить любой awaitable тип (ValueTask, Task.ConfigureAwait() etc).
Если совсем заморочиться, то можно попытаться то же самое добавить для ленивых enumerable, но для них будет слишком много ложных срабатываний.
[Request] диагностика для return task внутри try...catch
Пример кода из реального проекта (упростил):
Сопротивление бесполезно, угу
Как насчёт диагностики "утекания" промайза из области, обёрнутой в try{...} / using{...} ?
Промайза — т.к. кроме собственно Task<> так же может выстрелить любой awaitable тип (ValueTask, Task.ConfigureAwait() etc).
Если совсем заморочиться, то можно попытаться то же самое добавить для ленивых enumerable, но для них будет слишком много ложных срабатываний.
public Task<Something> TryGetSomethingAsync(string arg)
{
try
{
return GetSomethingAsync(arg);
}
catch (SomeException ex) // Nope.
{
throw HandleException(ex, arg);
}
}Сопротивление бесполезно, угу
Как насчёт диагностики "утекания" промайза из области, обёрнутой в try{...} / using{...} ?
Промайза — т.к. кроме собственно Task<> так же может выстрелить любой awaitable тип (ValueTask, Task.ConfigureAwait() etc).
Если совсем заморочиться, то можно попытаться то же самое добавить для ленивых enumerable, но для них будет слишком много ложных срабатываний.