Я принес вам решение проблемы с исключениями в C#. Но вам не понравится

К слову, достаточно ведь очевидная штука. Не могу понять, почему так не сделано

Я принес вам решение проблемы с исключениями в C#. Но вам не понравится

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

Я принес вам решение проблемы с исключениями в C#. Но вам не понравится

Хороший подход, но он на самом деле мало где применим — особенно с учетом достаточно бедной системы типов в C#. Например в тайпскрипте можно сделать функцию, которая отдает мне User | T, где T — тип, который отдаёт моя стратегия обработки исключительных ситуаций. И вот это подойдет уже везде, потому что где-то я смогу отдавать например дефолтного юзера, где-то тот же undefined, а где-то — объект с информацией о деталях ошибки.

А в C# есть опция только с дефолтным значением, потому что типов объединений там пока нет

Я принес вам решение проблемы с исключениями в C#. Но вам не понравится

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

Я принес вам решение проблемы с исключениями в C#. Но вам не понравится

Я написал статью на фоне своего опыта — а он говорит мне, что исключения C# разработчики используют повсюду — не только для нештатных ситуаций.

Я принес вам решение проблемы с исключениями в C#. Но вам не понравится

Так, является ли не найденный юзер нештатной ситуацией — зависит от контекста. Что касается нейминга — в статье, в вариантах, где мы можем вернуть нулл к имени добавлено OrDefault, где отдаем по out параметру, к имени добавлено Try, где монаду — ничего не добавлено, потому что там сам тип возвращаемого значения говорит о том, что юзера мы можем и не найти. К варианту с исключением можно добавить OrThrow — хуже не будет

Так же в самом низу статьи я отметил, что для нештатных ситуаций исключения как раз подходят

Я принес вам решение проблемы с исключениями в C#. Но вам не понравится

Ну разница то есть. В вашем случае, чтобы принять неверное решение, нужно знать детали платформы. А чтобы понять, что Maybe не гарантирует наличие данных, нужно знать значение этого слова на английском

Я принес вам решение проблемы с исключениями в C#. Но вам не понравится

Тут вот какая штука. Обрабатывать ошибки вызываемых методов — может и не обязанность моего класса. Но вот сообщать своим пользователям о том, как и когда он может свалится — это точно его обязанность. Так что да, хоть как-то но обрабатывать их все же придется.

Я принес вам решение проблемы с исключениями в C#. Но вам не понравится

Обновил немного статью

Я принес вам решение проблемы с исключениями в C#. Но вам не понравится

О том и говорю

Я принес вам решение проблемы с исключениями в C#. Но вам не понравится

Хм, ну давайте порассуждаем. Из любого метода и правда может вывалится исключение, но есть много случаев, когда я точно ожидаю, что метод не справится с задачей, и это штатная ситуация, которую я могу и должен обработать на месте. В случае с исключением, я ведь не знаю, всплывет оно или нет, и не знаю какое.

Условно, у меня есть гарантия, что вообще из любого метода может всплыть какое-то исключение, но логично считать, что это именно нештатная ситуация, которую надо обрабатывать наверху. А штатная ошибка — я хочу точно знать, какие штатные ошибки может отдавать метод, потому что рассчитываю обработать их на месте.

Напротив, именно в этом случае они замечательно подходят.

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

Любой код требует поддержки. Например поменяли мы конвенцию по именованию — нам надо все наши файлы с кодом перелопатить. Захотели документацию с русского на английский поменять — весь код меняем. Захотели вытащить часть нашего кода в отдельную сборку — и файлы с исключениями потратят наше время на то, чтобы решить, куда их девать.

На самом деле это проблема null, а не исключений.
Это проблема нулл, и это проблема исключений. Метод у меня идёт в базу искать юзера, и я понимаю, что он может и не найти. Но у него в документации нет типа исключения, я что, я заворачиваю его в catch(Exception). Метод отрабатывает, у меня отвалилась база, а мой код это не обработает, он обработает сценарий с ненайденным юзером. Плохо.

Я принес вам решение проблемы с исключениями в C#. Но вам не понравится

Я ничего не изобретал, просто рассказал про концепт. На рынке есть библиотеки и для Maybe/Option, и для Either/Result. И на хабре про них нередко пишут материалы. Моя задача была — концептуально сравнить монадический подход с другими, которые используются в шарпе.

Мы обновляем маркетплейс: расскажите нам, как лучше?

Сделайте ноду, самое очевидное

Мы делаем веб приложения ради экономии — но этот путь ведет нас во тьму

Прямо сейчас разрабатываю приложение на ней. В целом неплохо, но подводных камней пруд пруди.

Не нужно делать из фреймворков культ — они не настолько сложны, чтобы делить людей на React и Angular разработчиков

Думаю, две-три. Что кстати намного больше, чем у большинства здесь

Не нужно делать из фреймворков культ — они не настолько сложны, чтобы делить людей на React и Angular разработчиков

Ну это точно не ко мне. Мои статьи обсуждаются так активно, что лучшие из них просто не грузятся в хроме

Не нужно делать из фреймворков культ — они не настолько сложны, чтобы делить людей на React и Angular разработчиков

Ну слушай, если тебе нечего комментировать к техническим статьям, наверное не очень логично упрекать авторов нетехнических статей, нет?

Не нужно делать из фреймворков культ — они не настолько сложны, чтобы делить людей на React и Angular разработчиков

Вот кстати у меня такой же опыт. Я нанял к себе в команду фронтендеров, и частенько прошу добавить пару контроллеров на C# — по аналогии с существующими. И все норм, делают

Не нужно делать из фреймворков культ — они не настолько сложны, чтобы делить людей на React и Angular разработчиков

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

Опять же, учитывая качество этих коментов, он явно не из тех, кто откажется что-то написать, потому что не очень хорошо разбирается в теме

Не нужно делать из фреймворков культ — они не настолько сложны, чтобы делить людей на React и Angular разработчиков

Да, жаль только ты бы не стал её читать. Первые три страницы комментов в твоем профиле — ни один из них не комментирует технические статьи. Зато вот в мои статьи с мнением про индустрию ты заскакиваешь регулярно. Может как-то уже пора принять в себе, что заходишь сюда отдохнуть, а не поучиться?

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

Есть статья про разные модели типизаций — тут действительно глубоко копнул. Была статья про либу, которую делали с другом — тоже есть какой-то экспертный взгляд, я им поделился.

Когда в индустрии есть какая-то проблема, и я могу об этом поразмышлять — я это делаю. И люди читают. В чем проблема?