hVosttskyANA Функциональный C#. Часть 4. Обработка исключений

Угу, автор, как это обычно бывает, намеренно привёл отвратительную реализацию в противовес своему подходу:





А теперь перепишем, как это должно было быть:





Ну вот. Чисто, понятно. Хотя и здесь на контроллер возложено слишком много обязанностей, в нём выполняется многовато бизнес-логики.

Что касается кода, приведённого в конце, как решение всех проблем, то там уже очевидная проблема в коде, которого изначально и не было:





И вот это, "отлов ошибок" типа в функциональном стиле, чтобы потом сделать ровно тоже самое, что может сделать фильтр API, выгоды не видно совсем. Если же внутри всё написано в таком же ключе, то весь путь ошибки, проброшенный через эти "промисы" потеряется окончательно, всё ради того, чтобы залогировать корень проблемы, но не её путь. Хотя если каждый компонент по пути следования ошибки будет оборачивать в свою структуру, то... привет недоделанные исключения! Ещё строчку и файл нужно добавлять, тогда вообще будет сказка. Поехали на нашем велосипеде, чё ты, бросай это старьё

Ладно, если такой подход позволял раньше более или менее красиво обойти проблему коллбеков при асинхронном подходе, сейчас при наличии async/await, это зачем нужно, непонятно.

В общем, статья не убедительна, но как пример, что можно ещё так накостылить, показательна :) Где-то может будет удобно применить подобный подход, но плюсов не вижу. Функциональный стиль, здесь с большим натягом.
Конечно статья не убидительна, ведь ты её читал по диагонали судя по тому, что приводишь пример того, как типа должно быть ровно такой, с чего она начинается

hVosttlove_bachне понял, често что ты хотел сказать. и адвокат, и прокурор одновременно. "Видим, что Result тут приходит из сервисов", ну и что, каким это боком к исключениям?

Здесь речь идёт о том, что все исключения надо подавлять везде на самой ранней стадии, т.е. по сути придётся бороться с исключениями.вообще-то это не борьба, не подавление, а правило

ВМоисеев>hVostt, сегодня, 10:45 http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1297921&msg=21568042][21568042]
>...Вы что с деревьев слезли?... Что вы постоянно выдумываете какую-то фигню…
Опять за своё. Ну не понимают жующие желуди вкус апельсина.

Я то думал, приводя версию кода ( здесь и здесь ), что мне покажут как надо писать код или, по крайней мере, почему плох мой вариант кода.

Получил ответ так и так .

Прокомментировал
Добавлю:
Зачем в коде
public class EntityQuery : IQuery<EntityQueryContext, Entity> создается var list = new List<Entity>();
Не ДОЛЖЕН РАБОТАТЬ class EntityQuery с Entity.
С Entity и списком сущностей работает класс панели (UserControl), там они и определяются. И Entity не выносится за пределы панели.
На мой взгляд, class EntityQuery должен использовать обратный вызов метода панели. У меня бывает, что одна и та же выборка, обрабатывается разными методами панели.
Но моё решение, другие делают иначе. Но не стоит вешать любимый Вами ярлык на эти варианты.Я могу объяснить смысл и плюсы данного подхода.
Но кажется мне, что Вы не готовы слушать и понимать.
Судя по тому, что Вы не увидели, что общая часть уехала в базовый класс, и нет в итоге в EntityQuery выражения var list = new List<Entity>();

ВМоисеевС Entity и списком сущностей работает класс панели (UserControl), там они и определяются. И Entity не выносится за пределы панели.
Простите, а что Вы в базе храните?