Пример кода из реального проекта (упростил):

    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, но для них будет слишком много ложных срабатываний.

Здравствуйте, Sinix, Вы писали:

S>Как насчёт диагностики "утекания" промайза из области, обёрнутой в try{...} / using{...} ?
S>Промайза — т.к. кроме собственно Task<> так же может выстрелить любой awaitable тип (ValueTask, Task.ConfigureAwait() etc).
Я не сразу перевел это на русский Сделал реквест.

Здравствуйте, Sinix, Вы писали:

S>Если совсем заморочиться, то можно попытаться то же самое добавить для ленивых enumerable, но для них будет слишком много ложных срабатываний.

Похоже на проблему, которую решает наш "Access to disposed closure" Кейс интересный, но требует интрапроцедурный анализ, надо знать как реализован `GetSomethingAsync()`, что он целиком такой отложенный, вызов невиртуальный и бросить исключение сам по себе не может... У нас есть магическая техническая возможность "снаружи" метода (даже скомпилированного) узнать, async-ли он, но лишний раз пользоваться этим знанием не хочется (это знание из разряда хаков).

К сожалению, у нас нет двигла, позволяющего по произвольным выражениям языка понять, бросают ли они те или иные исключения — нет по причине того, что мы не можем в IDE позволить себе интрапроцедурный анализ, а значит практически любой вызов постороннего метода (оператора/конверсии/кучи других вызывающих конструкций) анализ будет переводить в состояние "Я ХЗ".

Перед тем, как делать какой-нибудь вкусный анализ, приходится оценить, насколько распознаваемый паттерн распространен и насколько его можно обобщить. Тут в try может быть просто что угодно, код какой угодно сложности. Ситуация с единственным вызовом async-метода под return'ом с чистыми аргументами и отсутствием других вызовов... по сравнению с тем, что можно вообще в try написать — это настолько звезды должны совпасть, что остается только погрустить о невозможности хоть сколько нибудь обобщить этот паттерн, поругаться на отсутствие исключений в системе типов/наличие исключений в языке (это по вкусу) и отложить идею куда-то в дальний ящик.

На моей памяти, единственное похожее, связанное и исключениями, что работает надежно и без false positive'ов — инспекция на redundant checked/unchecked (что мол внутри нет ни одного "опасного" арифметического оператора/конверсии), только из-за того, что их область "действия" не распространяется на вызванные методы и набор checked-операторов заранее хорошо известен.

Здравствуйте, Пельмешко, Вы писали:


П>Похоже на проблему, которую решает наш "Access to disposed closure" Кейс интересный, но требует интрапроцедурный анализ, надо знать как реализован `GetSomethingAsync()`, что он целиком такой отложенный, вызов невиртуальный и бросить исключение сам по себе не может... У нас есть магическая техническая возможность "снаружи" метода (даже скомпилированного) узнать, async-ли он, но лишний раз пользоваться этим знанием не хочется (это знание из разряда хаков).

Не в порядке спора, чисто для разобраться.

А тут точно интрапроцедурный анализ нужен?
По соглашению, методы возвращают горячую таску. Т.е. для отлова потенциальной ошибки достаточно отследить, что таску вернули из try scope без получения результата таски.
И за "возврат" считать только тривиальные варианты: присвоение в переменную / аргумент / поле и собственно return. Передачу в другие методы внутри try scope игнорим.

Всё, что сложнее — не окупится, тут полностью согласен

Здравствуйте, Sinix, Вы писали:

S>Всё, что сложнее — не окупится, тут полностью согласен
У меня есть острое желание написать супернаивную реализацию и светить hint (настраиваемый), и посмотреть чем это закончится.

Здравствуйте, qxWork, Вы писали:

W>У меня есть острое желание написать супернаивную реализацию и светить hint (настраиваемый), и посмотреть чем это закончится.
Да-да-да, что-то такое и имел в виду