Бонусные баллы, если сделаешь это без использования лишнего внешнего блока task (внутри у тебя и так уже таск есть)

printfn "Upload attempt %i for the file %s has failed:\n%s" r f ex.Message мне не нравится — я считаю, что лучше распечатать всё исключение через %A, чтоб видеть стектрейс

Там всё равно какой стектрейс - я даже Error обратно возвращаю строкой

try return Ok x() with | ex -> return Error ex Попахивает паттерном. Предлагаю вынести в отдельную функу, а то там и так уже уровней вложенности слишком уж много :)

Это дело!

Ну, это просто мои мысли. Дальше уже дело автора — что менять, а что нет по результатам моего ревью

Вроде всё прочитал. Мне апишечка тамошняя не нравится. Мне кажется, она будет вот так убого выглядеть что из F#, что из C#.

Если хочется сделать красивый код — я бы заврапал её в чуть большее количество функций, которые бы можно было по-отдельности протестировать, например.

Polly?

SftpClient срамной

О, да

Async.FromBeginEnd это ни в какие ворота, да :)

Polly в данном случае мне тоже не нравится, но её уже только из F# неудобно использовать. Мб вот она — хороший кандидат на то, чтоб заврапать

В компутейшонал экспрешн?

Action<Exception, TimeSpan, int, Context> можно попробовать сократить до Action<_, _, _> — по крайней мере, я бы так поступил. Мб какие-то из типов придётся оставить.

Хм... попробую. Просто если внутрь полли посмотреть - там 256 вариантов типов экшонов

Пока что сходу вижу: |> Async.AwaitTask можно выкинуть и просто юзать task вместо async, если уж всё равно нам нужно сразу эти таски запускать.

А как их потом в Async.Parallel запихнуть?

А как их потом в Async.Parallel запихнуть?

А ты их запихивай в Task.WhenAll!

Ну, впрочем, это уже повод задуматься про асинк — может быть, он тут пригодится, ок :)

У тасков больно уж убогонький API для получения результата синхронно.

Но тогда можно, например, так: tasks |> Seq.map Async.AwaitTask |> Async.Parallel |> Async.RunSynchronously Предпочесть этот или тот подход — вопрос, скорее, философский.

Можно прикинуть, где аллокаций больше будет, и вот это всё, но по сути однофигственно, используй какой больше нравится.

Можно прикинуть, где аллокаций больше будет, и вот это всё, но по сути однофигственно, используй какой больше нравится.

Спасибо!

А object expressions может в проперти? Не могу найти пример использования

Может. Только с List<T> проблема в том, что Count — sealed.

@PimenovDenis А что у тебя за задача? Может ее как-то иначе можно решить?

try return Ok x() with | ex -> return Error ex Попахивает паттерном. Предлагаю вынести в отдельную функу, а то там и так уже уровней вложенности слишком уж много :)

Я как раз недавно коллегу за такое отчитывал) Думаю, что эксепшны возвращать это плохой паттерн. Или их кидать надо, или свои эрроры возвращать

Я как раз недавно коллегу за такое отчитывал) Думаю, что эксепшны возвращать это плохой паттерн. Или их кидать надо, или свои эрроры возвращать

Ну, тут от задачи зависит. В данном случае нормально, кажется? Представь, как раскукожит Async.Parallel, если таски в нём начнут завершаться ошибками.

Согласен) Я скорее про паттерн) что в общем так делать не нужно, только в спец случаях

Да, соглашусь.

Ну, тут от задачи зависит. В данном случае нормально, кажется? Представь, как раскукожит Async.Parallel, если таски в нём начнут завершаться ошибками.

Угу. Первый же эксепшн раком всё ставит, пардон май Фрэнч

Можно прикинуть, где аллокаций больше будет, и вот это всё, но по сути однофигственно, используй какой больше нравится.

Аллокации - посмотреть в fsi ?

Аллокации - посмотреть в fsi ?

Я скорее имел в виду «обдумать» :)

Да можно ж оба варианта запустить в fsi и посмотреть :)

Что посмотреть? FSI где-то собирает статистику по аллокациям?

Кстати - там же не эксепшон возвращается, а Error of string

fsi вроде при #time "on" пишет не только время выполнения, но и статистику GC

Надо же, я этого не знал / забыл.

Но спасибо за идею - буду экспериментировать!

По поводу эксепшена - в некоторых случаях и правильно что после эксепшена всё падает. Мы 3 раза честно попытались с полли, если там коннекта нет, то смысл пробовать для каждого файла (а если их там 10 000)? Другое дело, что могут быть ошибки специфичные для конкретного файла - например если файл уже существует на SFTP - имхо как раз такие случаи лучше перехватывать и выносить в Result.

Про connect / disconnect на каждый аплоад - так конечно проще и надежнее, но у меня был случай когда коннект сам по себе занимал 5-10 секунд, а заливка файла укладываласть в 100мс.

Это в примере загрузка всех файлов на локалхост. В реальной жизни все фтп разные. Не смогли загрузить один - не значит, что все остальные не получится (я из за этого-то и начал этот огород городить)

К коннекту это тоже относится.

Я как раз недавно коллегу за такое отчитывал) Думаю, что эксепшны возвращать это плохой паттерн. Или их кидать надо, или свои эрроры возвращать

Почему плохой? В объекте исключения есть все типовая информация об ошибке из коробки. Свой велосипед в 99% случаев будет не лучше

Почему плохой? В объекте исключения есть все типовая информация об ошибке из коробки. Свой велосипед в 99% случаев будет не лучше

неидиоматично? других возражений не вижу

Почему плохой? В объекте исключения есть все типовая информация об ошибке из коробки. Свой велосипед в 99% случаев будет не лучше

Тогда надо совсем по-иному делать - try catch внутри таска должен разбить все эксепшоны на ретраибл и нет. В полли указать этот тип, чтобы продолжать попытки, когда это нужно...

Много чего можно навернуть :)

Про connect / disconnect на каждый аплоад - так конечно проще и надежнее, но у меня был случай когда коннект сам по себе занимал 5-10 секунд, а заливка файла укладываласть в 100мс.

Например, группировать по адресу и юзеру и все файлы в группе заливать в одной сессии.

Тогда надо совсем по-иному делать - try catch внутри таска должен разбить все эксепшоны на ретраибл и нет. В полли указать этот тип, чтобы продолжать попытки, когда это нужно...

А в честь чего вдруг таск знает при каких исключениях надо повторять? Политику обработки исключений желательно иметь отдельно. Опять-таки и в этом случае велосипедная конструкция вместо исключения будет хуже.

А в честь чего вдруг таск знает при каких исключениях надо повторять? Политику обработки исключений желательно иметь отдельно. Опять-таки и в этом случае велосипедная конструкция вместо исключения будет хуже.

Я же говорю - до бесконечности улучшать. Именно поэтому ретрай стоит просто - на любой эксепшн.

Я же говорю - до бесконечности улучшать. Именно поэтому ретрай стоит просто - на любой эксепшн.

У Реймонда Чена была очень проникновенная статья про ретрай на любую ошибку. Особенно если этот ретрай вложенный.

На любую никто не предлагает

https://blogs.msdn.microsoft.com/oldnewthing/20051107-20/?p=33433

Прочитал Чена. Познавательно. Напоминает хрестоматийный пример (не про ритрай) про программу спутника, один модуль которой ожидал, что все величины в СИ, а другой - в имперской.

У меня вывод из статьи немного иной - не ретраи опасны, а мискоммуникация

и 30-секундные таймауты)

Почему плохой? В объекте исключения есть все типовая информация об ошибке из коробки. Свой велосипед в 99% случаев будет не лучше

Потому что как правильно обработать эксепшн лучше всего как раз в том месте где этот эксепшн произошел. Если не знаешь как - кидай эксепшн дальше, если знаешь - передавай DU с эррором. Передавать эксепшн очень странно, как будто это ожидаемый результат

Прочитал Чена. Познавательно. Напоминает хрестоматийный пример (не про ритрай) про программу спутника, один модуль которой ожидал, что все величины в СИ, а другой - в имперской.

С сильной типизацией этого бы не было

Тогда надо совсем по-иному делать - try catch внутри таска должен разбить все эксепшоны на ретраибл и нет. В полли указать этот тип, чтобы продолжать попытки, когда это нужно...

вот одобряю, так сам и делал)

https://eiriktsarpalis.wordpress.com/2017/02/19/youre-better-off-using-exceptions/

https://twitter.com/zaid_ajaj/status/1036369062408998912?s=09

Потому что как правильно обработать эксепшн лучше всего как раз в том месте где этот эксепшн произошел. Если не знаешь как - кидай эксепшн дальше, если знаешь - передавай DU с эррором. Передавать эксепшн очень странно, как будто это ожидаемый результат

Поддержу. Польза DU для ошибок в том, что это закрытое множество. Чуть больше информации о поведении функции. :)

Поддержу. Польза DU для ошибок в том, что это закрытое множество. Чуть больше информации о поведении функции. :)

@antyadev в докладах говорил о том, что для неожиданных исключений они делали метку type Exceptions = ... | Bug of Exception И изучали его

Мне кажется, в этом смысла уже меньше.

Для большого приложения есть смысл. Неучтеные состояния явно тегаются и впоследствии их можно учесть.

ну я думаю что смысл тут отделить методы которые могут бросать эксепшны от тех которые не могут

но что-то кажется, что любые методы могут их бросать)

ThreadAbortException может кто угодно бросить.

Любой GC safepoint, если я правильно помню.

да и баг где угодно может быть)

https://twitter.com/zaid_ajaj/status/1036369062408998912?s=09

Опять говнопример

Опять говнопример

Ищи возможности!)

Я к тому, что в выбранной архитектуре довольно тяжело прокинуть имя темплейта для отображения, например

А для wpf это критично

Опять говнопример

Нормальный пример.

Привет! Знаком с F#?

ThreadAbortException может кто угодно бросить.

Но его и ловить бесполезно

Для большого приложения есть смысл. Неучтеные состояния явно тегаются и впоследствии их можно учесть.

Это не добавляет информации. Только вопрос удобства обработки.

Это не добавляет информации. Только вопрос удобства обработки.

Добавляет при использовании приложения

Добавляет при использовании приложения

Объясни.

Но его и ловить бесполезно

Не совсем ?

Объясни.

Всмысле все что с тегом Bug в логах отправляется на внимательное изучение. И исправляется.

Всмысле все что с тегом Bug в логах отправляется на внимательное изучение. И исправляется.

А в чем отличие от нежданных исключений, которые ловятся где-то наверху и записываются в лог?

Но его и ловить бесполезно

Его глушить бесполезно. А ловить и освобождать ресурсы смысл есть.

ок согласен

Привет! Знаком с F#?

Он спамер

В другом чате спамит

Доставай банхаммер

А в чем отличие от нежданных исключений, которые ловятся где-то наверху и записываются в лог?

В том, что они все же обработанные и вполне себе укладываются в состояние приложения. Т. е. Разработчик учитывает в контролфлоу состояние возможного бага и не полагается на Exception в контролфлоу

Доставай банхаммер

Он у тебя давно

done

Насколько давно? :D

А то я всё фридриха зову

А в чем отличие от нежданных исключений, которые ловятся где-то наверху и записываются в лог?

как я понимаю, есть ожидаемые косяки (файл не найден, коннекшн оборвался), а есть ошибки, допущенные при написании кода, типа нулл референса. И иногда их удобно обрабатывать и логировать по-разному

Насколько давно? :D

Минуты 3

Аа, ладно

:D

Нормальный пример.

С точки зрения реального программирования - нет

Я там выше озвучил , почему

Всмысле все что с тегом Bug в логах отправляется на внимательное изучение. И исправляется.

Unhandled эксепшны в логах тоже должны отправляться на внимательное изучение =)

Unhandled эксепшны в логах тоже должны отправляться на внимательное изучение =)

В теории их быть не должно, конечно. Но это в теории