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

Ну, можешь про свое реальное программирование рассуждать в @fsharp_flood.

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

Так если ты его сверху ловишь, то оно тоже обработанное будет.

Ну, можешь про свое реальное программирование рассуждать в @fsharp_flood.

Не ссоритесь пожалуйста

Так если ты его сверху ловишь, то оно тоже обработанное будет.

Это уже про другое

Ну, можешь про свое реальное программирование рассуждать в @fsharp_flood.

Ты не выспался, что ли? Я честно пытался прикрутить Wpf.elmish к своему проекту. У меня не получилось. Сценарий соответственно был самый обычный для wpf приложений

Это уже про другое

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

Ты не выспался, что ли? Я честно пытался прикрутить Wpf.elmish к своему проекту. У меня не получилось. Сценарий соответственно был самый обычный для wpf приложений

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

Если кому интересно, могу развернуть аргументы про elmish.wpf

Ты не выспался, что ли? Я честно пытался прикрутить Wpf.elmish к своему проекту. У меня не получилось. Сценарий соответственно был самый обычный для wpf приложений

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

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

Чем раньше отловишь исключение, тем меньше у тебя будет круг поиска

Если кому интересно, могу развернуть аргументы про elmish.wpf

Было бы интересно

Ок, аргументирую, почему это г-нопример.

1. Типичным сценарием построения UI в WPF является написание модели и назначение ей шаблона отображени

*отображения

Соответственно, в главном окне(или где-то еще) у нас есть ContentPresenter, который в DataContext принимает модель плюс DataTemplateSelector, который на основании модели принимает решение о том, какой шаблон подставить

Данные же примеры заточены на генерацию конкретного UI под конкретные модели - нормалный такой html-like подход. Т.е. есть модель, я генерю ей отображение, и типа все ок

Проблема начинается, когда надо разделить модель и отображение

Плюс желательно, чтобы генератор моделей (в нашем случае update, как я понимаю) ничего не знал об отображении

Чем раньше отловишь исключение, тем меньше у тебя будет круг поиска

Если ты просто не будешь хэндлить непонятные эксепшны и они пойдут наверх, то там будет стектрейс и круг поиска такой же)

А скорее мог подставить некий ключ в сгенерированную модель, по которому UI сможет выбрать нужный способ отображения

Так вот

Текущая реализация Elmish.wpf на динамиках этого сделать, к сожалению, не очень позволет

@vshapenko То, что модель не подходит под твои влажные фантазии — не значи, что она говно. Есть куча приложений, которые можно без проблем написать в форма SPA и TEA.

Объясняю еще раз. Это не фантазии

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

Просто подход, который ок в вебе, здесь не совсем применим

Если ты просто не будешь хэндлить непонятные эксепшны и они пойдут наверх, то там будет стектрейс и круг поиска такой же)

А тут ты ловишь все исключения и пишешь их в Result<'a,Exceptions>, где в Exceptions есть | Bug. Это важно, чтоб всегда быть в одном контролфлоу

В силу разного подхода к генерации UI

В html страница содержит данные

Проблема начинается, когда надо разделить модель и отображение

Как раз неделю назад очень похожую тему обсуждали с DustinMorris из жирафа) Он хотел один к одному мапить вьюху на модель, и не хотел добавлять ViewModel куда можно произвольные данные независимо от модели пихать, но я его смог убедить что это бывает полезно

Как раз неделю назад очень похожую тему обсуждали с DustinMorris из жирафа) Он хотел один к одному мапить вьюху на модель, и не хотел добавлять ViewModel куда можно произвольные данные независимо от модели пихать, но я его смог убедить что это бывает полезно

Ну вот да

https://github.com/giraffe-fsharp/Giraffe.Razor/issues/5

И на десктопе этот сценарий значительно более частый, чем на вебе

Соответственно, если фреймворк пишется без поддержки этого сценария, он довольно-таки сильно ограничивает доступные оптимальные пути разработки

А тут ты ловишь все исключения и пишешь их в Result<'a,Exceptions>, где в Exceptions есть | Bug. Это важно, чтоб всегда быть в одном контролфлоу

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

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

Зачем везде вставлять трай-кетчи? Делается ровно одна обертка и вуаля.

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

Теряешь контролфлоу - получаешь неопределенность

Так что минимальное зло есть, да, но зато получаешь управляемость

Теряешь контролфлоу - получаешь неопределенность

У исключений флоу простой и предсказуемый. А еще и бесплатный, если их не бросать.

У исключений флоу простой и предсказуемый. А еще и бесплатный, если их не бросать.

Вот да, специально их никто не бросает, кстати

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

Хм... проблема обычно в том, что сами ошибки - множество открытое

Хм... проблема обычно в том, что сами ошибки - множество открытое

И мы превращаем его в закрытое

И мы превращаем его в закрытое

Не превращаем - или сохраняем Exception (сам объект), который вполне себе открытый или усекаем до того или иного закрытого множества.

Не превращаем - или сохраняем Exception (сам объект), который вполне себе открытый или усекаем до того или иного закрытого множества.

Усекаем, ок.

Усекаем, ок.

И в процессе теряем информацию об ошибке, что практически не есть гуд. Поэтому я ничего не имею против Result, но вторым параметром у меня в нем Exception

Вопрос один - на каком уровне иерархии нам полезна информация об исключении?

Точнее, полная информация

И в процессе теряем информацию об ошибке, что практически не есть гуд. Поэтому я ничего не имею против Result, но вторым параметром у меня в нем Exception

Нет. Bug of Exception сохраняет информацию

Вопрос один - на каком уровне иерархии нам полезна информация об исключении?

На всех. Нам нужно преобразование известных ошибок на границах уровней абстракции, но терять информацию снизу (которая InnerException) низзя.

Нет. Bug of Exception сохраняет информацию

Для Bug of Exception закрытое внезапно протекает

Я на это смотрю с той точки зрения, что, если у меня случилась такая фигня, то должна быть возможность понять, что:1. фигня произошла 2. что с ней делать

То, что фигня произошла - это просто текст ошибки, по идее

Что делать - полный текст эксепшна в логах

Иначе произойдет встраивание эксепшна в логику работы, что, имхо, не есть гуд

Иначе произойдет встраивание эксепшна в логику работы, что, имхо, не есть гуд

Почему? Ты можешь отщипнуть от эксепшена известное тебе подмножество и повесить на него логику обработки. Его собственно за этим и придумали

У исключений флоу простой и предсказуемый. А еще и бесплатный, если их не бросать.

Неа, не бесплатно

Почему? Ты можешь отщипнуть от эксепшена известное тебе подмножество и повесить на него логику обработки. Его собственно за этим и придумали

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

Для известных исключений проще вывести типы ошибок плюс запись в лог

С неизвестными, в целом , то же самое

UnknownError msg

Зависит от контекста сильно

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

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

Скорее залогировать

ERROR: S client not available

И наверх кинуть Unknown

С неизвестными, в целом , то же самое

Не то же самое - неизвестные всегда открытое множество.

Просто если я начинаю оперировать в логике исключениями, для меня это скорее знак, что что-то пошло не так

UnknownError msg

this

И наверх кинуть Unknown

А зачем? Шансов обработать корректно больше не станет, а информация пропадет.

Ну у тебя будет дефолтный обработчик на Unknown

Например, рестарт дерева акторов

Например, рестарт дерева акторов

В ответ на StackOverflow? Сомнительно

И наверх кинуть Unknown

А вот кидать зачем я хз. Если у тебя в Result уже и так состояние есть, что приложение знает что оно в состоянии ошибки. И ты с ним работаешь как с обычным Result

В ответ на StackOverflow? Сомнительно

Так, давай определимся. Мы о каком классе ошибок говорим?

Например, рестарт дерева акторов

Авторы это немного не о том.

Ну я для примера

Так, давай определимся. Мы о каком классе ошибок говорим?

Об общем подходе в F#, не углубляясь в специфику фреймворков где кидать ошибки это нормально

Об общем подходе в F#, не углубляясь в специфику фреймворков где кидать ошибки это нормально

Это я про акку)

Хотя там тоже РОП подходит, но там встроенный обработчик. Это специфичный случай кмк

Ну я бы все же в общем случае предложил бинарный подход

То, что можем, обрабатываем

С остальным разбираемся

Попутно увеличивая количество известных нештатных ситуаций

И заворачиваем их в нашу доменную область

Ну и пишем тесты на всякое

Ну и пишем тесты на всякое

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

Зачем везде вставлять трай-кетчи? Делается ровно одна обертка и вуаля.

Потому что разговор был, нужен ли Bug of Exception. Баг может быть в любой функции => надо любую функцию надо оборачивать в трайкетч

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

Угу. Проблема в том, что никогда полностью не уверен, где выстрелит

Я за то что если факап ожидаемый, то это и не факап вовсе, а просто другой результат работы функции. Т.е. это нормально ожидать от хттп транспорта таймаута или ещё чо. Чтобы не заебаться, все возможные случаи можно поделить на - ретраибл и неретраибл. Ретраибл после N ретраев становится неретрабил. Реакция на неретраибл тоже ожидаемая должна быть. И это нормально менять флоу в зависимости от исхода, очень конечно спасают DU. Но вот ожидать там стаковерфлоу или аутофмемори точно не стоит, но узнать о нём post mortem надо. Поэтому лазейка для ВНЕЗАПНЫХ крашей нужна, чтобы на верхнем уровне залогировать и умереть.

Я за то что если факап ожидаемый, то это и не факап вовсе, а просто другой результат работы функции. Т.е. это нормально ожидать от хттп транспорта таймаута или ещё чо. Чтобы не заебаться, все возможные случаи можно поделить на - ретраибл и неретраибл. Ретраибл после N ретраев становится неретрабил. Реакция на неретраибл тоже ожидаемая должна быть. И это нормально менять флоу в зависимости от исхода, очень конечно спасают DU. Но вот ожидать там стаковерфлоу или аутофмемори точно не стоит, но узнать о нём post mortem надо. Поэтому лазейка для ВНЕЗАПНЫХ крашей нужна, чтобы на верхнем уровне залогировать и умереть.

+1

Я за то что если факап ожидаемый, то это и не факап вовсе, а просто другой результат работы функции. Т.е. это нормально ожидать от хттп транспорта таймаута или ещё чо. Чтобы не заебаться, все возможные случаи можно поделить на - ретраибл и неретраибл. Ретраибл после N ретраев становится неретрабил. Реакция на неретраибл тоже ожидаемая должна быть. И это нормально менять флоу в зависимости от исхода, очень конечно спасают DU. Но вот ожидать там стаковерфлоу или аутофмемори точно не стоит, но узнать о нём post mortem надо. Поэтому лазейка для ВНЕЗАПНЫХ крашей нужна, чтобы на верхнем уровне залогировать и умереть.

вот в том-то и прикол что все что ты говоришь "на верхнем уровне" надо опять же обернуть в тот DU Типа type Exceptions = ... | WTFISIT of exception и тогда программа дальше будет работать с Result< 'a , Exceptions> а не ломая все на своем пути исключение будет всплывать в верх по стеку.

вот в том-то и прикол что все что ты говоришь "на верхнем уровне" надо опять же обернуть в тот DU Типа type Exceptions = ... | WTFISIT of exception и тогда программа дальше будет работать с Result< 'a , Exceptions> а не ломая все на своем пути исключение будет всплывать в верх по стеку.

не, на верхнем уровне надо сделать один трай кетч, для падений от всякого говна а по ходу программы лично я пользуюсь либо Choice1of2 или Result или Option

throw пользуюсь только если я попадаю в ситуацию где ну совсем пиздец и надо чтобы отработал тот самый верхний блок, без всяких option

т.е. throw в моём коде - это гарантированная смерть аппликейшна

То есть panic