насчет того что можно свалить пейлоадом кривым в 500, это даже в рельсе есть и никто не фиксит, все знают где лежит дежурный костыль

То бишь эксепшены надо таки ловить? А не надеятся на супервизора?

и где он лежит?

в фениксе?

по-хорошему, мы смотрим в логи, видим что рестартуется. фиксим.

итеративно

в фениксе?

санитайзер в плаг первым ставишь и все

санитайзер в плаг первым ставишь и все

куда? в эндпоинт?

https://ru.hexlet.io/courses/erlang_101/lessons/practical_erlang_let_it_crash/theory_unit

Лично я не люблю эксепшены. Они ведь на то и эксепшены, что сигнализируют об исключительной ситуации, когда надо что-то чинить. Тогда это 500, без дураков. Но когда клиент присылает данные - моя задача провести валидацию То есть выяснить, могу ли я в принципе с ними работать. Если нет - то никакой это не эксепшен, а невалидный запрос. И на тебе в ответ 400 с подробностями, чтобы ты мог на своей стороне починить. Поэтому, например, я люблю всё, что приходит через http (параметры, json) сначала принимать как текст, а потом уже контролируемо парсить.

эксепшены можно перехватывать, а можно коды ошибок анализировать, без разницы. Эксепшены просто удобнее, потому что не надо городить railway error handling

@spscream Почему либа construct, а на кексе - struct?

Лично я не люблю эксепшены. Они ведь на то и эксепшены, что сигнализируют об исключительной ситуации, когда надо что-то чинить. Тогда это 500, без дураков. Но когда клиент присылает данные - моя задача провести валидацию То есть выяснить, могу ли я в принципе с ними работать. Если нет - то никакой это не эксепшен, а невалидный запрос. И на тебе в ответ 400 с подробностями, чтобы ты мог на своей стороне починить. Поэтому, например, я люблю всё, что приходит через http (параметры, json) сначала принимать как текст, а потом уже контролируемо парсить.

Вот да. У себя я использую protobuf. Там валидатор типов генерится автоматически, как часть парсера. Ооочень удобно, и экономит кучу времени. Но валидатор значений, их логической непротиворечивости - это уже руками разбирать.

переименовались вчера, там же в хексе и construct уже

Если посмотреть в ретроспективе то мы даже на плюсах двигались в сторону let-it-crash хотя и сами об этом не догадывались

решили, что может быть путаница из-за названия поэтому Struct -> Construct

переименовались вчера, там же в хексе и construct уже

мне кажется, или npm запахло)

А чем railway плох?

Норм, чё

только удалить надо

hex - гребаная дыра, если ты что-то туда выложил, то уже нельзя убрать :)

Если посмотреть в ретроспективе то мы даже на плюсах двигались в сторону let-it-crash хотя и сами об этом не догадывались

Таки скорее не let it crash, а it may crash.

Вот да. У себя я использую protobuf. Там валидатор типов генерится автоматически, как часть парсера. Ооочень удобно, и экономит кучу времени. Но валидатор значений, их логической непротиворечивости - это уже руками разбирать.

Только это сойдешь с ума, чтобы понять там какое поле имеет неверный тип ?

Давайте сделаем свой кекс - с монадами и ооп-перебежчиками

А чем railway плох?

в эликсире неудобен, в отличие от того же rust.

Только это сойдешь с ума, чтобы понять там какое поле имеет неверный тип ?

пока проблем не было) может ещё не сталкивался, конечно

Кстати, let-it-crash вовсе не означает, что не надо обрабатывать ошибки.(так в статье написано). Речь о разделении логики основного сценария и логики обработки ошибок. Всему своё место.

И восходит эта идея к Модели Акторов.

с наступающим всех

пока проблем не было) может ещё не сталкивался, конечно

Ни разу не писали nil в required поле?) повезло)

Но protobuf хорош, это да

Кстати, let-it-crash вовсе не означает, что не надо обрабатывать ошибки.(так в статье написано). Речь о разделении логики основного сценария и логики обработки ошибок. Всему своё место.

А рекламируют как раз как будто не надо обрабатывать ошибки.

с наступающим всех

и вас

Ни разу не писали nil в required поле?) повезло)

я на эрланге его использую) так что да, не писал)

а что эксепшены в эликсире как-то сильно отличаются от плюсов или там рубей?

Почему плохо бросать ошибки? Потому что это приводит к коду с неизолированными побочными эффектами. То есть, внутри функции хорошо перехватывать ошибку при попытке парсить текст в число. Но наружу лучше отдать простой кортеж в любом случае.

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

почему их кто-то не любит? нормальный способ оповестить вышестоящее начальство о проблемах

А рекламируют как раз как будто не надо обрабатывать ошибки.

когда не сильно нужно, можно и не обрабатывать

Почему плохо бросать ошибки? Потому что это приводит к коду с неизолированными побочными эффектами. То есть, внутри функции хорошо перехватывать ошибку при попытке парсить текст в число. Но наружу лучше отдать простой кортеж в любом случае.

Ну с такой логикой и railway error handling - плохо

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

а так - это тот же самый REH

Eugene Чем?

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

я принял всю боль. Прямо вот в 4 из 5 проектов обосрался

Давайте сделаем свой кекс - с монадами и ооп-перебежчиками

можно просто начать писать на Scala

Eugene Чем?

тем же самым "неизолированными побочными эффектами"

какая разница, вернуть ошибку в виде кортежа или в виде эксепшена?

зато эксепшен легко переправить выше, если у функции нет компетенции реагировать на эту ошибку

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

Так ведь нет же. Есть шаги вычислений. Вся цепочка в совокупности либо возвращает {:ок, ответ}, либо {:ашипка, {:плохой_жсон, подробности}}. Или какая другая ошибка. Всё чисто, без побочных. Обработал корректный ответ - после этого можешь спокойно промэтчить и обработать ошибки. Говоря об эксепшенах, не стоит забывать, что они бросаются в пределах одного call stack-а. То есть, в пределах одного (однопоточного) процесса.

Так ведь нет же. Есть шаги вычислений. Вся цепочка в совокупности либо возвращает {:ок, ответ}, либо {:ашипка, {:плохой_жсон, подробности}}. Или какая другая ошибка. Всё чисто, без побочных. Обработал корректный ответ - после этого можешь спокойно промэтчить и обработать ошибки. Говоря об эксепшенах, не стоит забывать, что они бросаются в пределах одного call stack-а. То есть, в пределах одного (однопоточного) процесса.

Дык в самом первом элементе цепочки я лювлю исключения от всех нижестоящих цепочек и возвращаю {:ашипка}

а в функция обрабатывающая жсон вполне может кинуть исключение, вместо возврата кортежа {:ашипка, :плохой жсон}

*отредактировал ответ.

@spscream А вот эту либу вы видели? https://github.com/appcues/exconstructor Тоже похожий функционал... В чём различия?

Так ведь нет же. Есть шаги вычислений. Вся цепочка в совокупности либо возвращает {:ок, ответ}, либо {:ашипка, {:плохой_жсон, подробности}}. Или какая другая ошибка. Всё чисто, без побочных. Обработал корректный ответ - после этого можешь спокойно промэтчить и обработать ошибки. Говоря об эксепшенах, не стоит забывать, что они бросаются в пределах одного call stack-а. То есть, в пределах одного (однопоточного) процесса.

Ага, вот в генсервере и ловим эксепшены

я к тому, что принципиальной разницы между REH и эксепшенами нет.

только вот REH неудобен, надо либо with использовать либо городить костыли в виде макросов, либо страдать от вложенных структур

@spscream А вот эту либу вы видели? https://github.com/appcues/exconstructor Тоже похожий функционал... В чём различия?

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

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

санитайзер в плаг первым ставишь и все

Так куда все же плаг ставить, в эндпоинт?

+1

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

да все еще проще - решаешь для каждого случая, как удобнее.

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

Вам хорошо, а мне выбирать теперь ))

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

Я как-то привык к эксепшенам в D. У меня там тоже все разбито на кучу легковесных тасков (файберы/корутины) со своими стеками.

Кстати, а какие грабли были с with?

ERROR: S client not available

вот так примерно

Вам хорошо, а мне выбирать теперь ))

Будь мужиком, напиши свою :D

в санитайзере сделать разбор и возвращать если не так

А, значит все-таки в эндпоинт, я так и понял

или отдавать отбратно конн чтобы остальные шаги его забирали

Будь мужиком, напиши свою :D

Не, я лучше вашу допишу. Если вдруг чего-то не хватит

Ну это норм

Тебя хоть найти можно, в отличие от авторов той либы

))

мы эту либу в проде используем, поэтому поддерживать её будем всегда

@spscream А вот эту либу вы видели? https://github.com/appcues/exconstructor Тоже похожий функционал... В чём различия?

> handles map-vs-keyword-list, string-vs-atom-keys, and camelCase-vs-under_score адово как-то

> handles map-vs-keyword-list, string-vs-atom-keys, and camelCase-vs-under_score адово как-то

Ну пацаны постарались учесть всё

Хотя, может это и не очень грамотно

кстати там в Readme вроде не все кейсы использования, в тестах более подробно можно посмотреть

https://github.com/appcues/exconstructor/blob/master/lib/exconstructor.ex#L158-L159 String.to_atom это же binary_to_atom, а не binary_to_existing_atom?

/leave

/leave

короче, это нельзя в прод

что за /leave в треде?

Eugene Опять же, в рамках процесса. Как только задача выходит за рамки (например, обращение к БД или другим http-сервисам) - там уже ситуация немного меняется. Например, ждёшь ты ответа от сервиса до таймаута - процесс по таймауту умирает, эксепшена нет. Или твой процесс прилинкован к другому процессу, и они умирают вместе... А так - в подходящих местах эксепшены очень удобно ловить. Просто эти "подходящие" места тобой должны восприниматься как что-то "внутри" твоего мыслительного контекста. То есть, это я так стараюсь к эксепшенам подходить. Несмотря на то, что разные фреймворки дают стандартный хендлинг, я не люблю бросать эксепшены из контроллеров, потому что это делает логику их обработки размазанной по разным местам кода, в том числе и не твоего.

https://github.com/appcues/exconstructor/issues/5 ок, претензия снимается, но все равно как-то не очень кошерно

Короче, let it crash - не нужен. ?

Ключевые слова - error core. Данные надо хранить там, где их не заденет падение того что их обрабатывает. Ценные данные надо хранить дальше. Let it crash нужен, для остального есть руби.

Eugene Опять же, в рамках процесса. Как только задача выходит за рамки (например, обращение к БД или другим http-сервисам) - там уже ситуация немного меняется. Например, ждёшь ты ответа от сервиса до таймаута - процесс по таймауту умирает, эксепшена нет. Или твой процесс прилинкован к другому процессу, и они умирают вместе... А так - в подходящих местах эксепшены очень удобно ловить. Просто эти "подходящие" места тобой должны восприниматься как что-то "внутри" твоего мыслительного контекста. То есть, это я так стараюсь к эксепшенам подходить. Несмотря на то, что разные фреймворки дают стандартный хендлинг, я не люблю бросать эксепшены из контроллеров, потому что это делает логику их обработки размазанной по разным местам кода, в том числе и не твоего.

Процесс может не умирать, а сам обрабатывать таймауты. Например в том же HTTPoison можно указать таймаут. Бросать эксепшены из контроллеров действительно не лучшая идея, а вот из парсера json вполне можно

Ключевые слова - error core. Данные надо хранить там, где их не заденет падение того что их обрабатывает. Ценные данные надо хранить дальше. Let it crash нужен, для остального есть руби.

Типа стейты держать в процессах отдельно от процессов с ними работающими? Причем они должны быть еще и не связанными. Тоже решение, но местами это выглядит как оверинжиниринг.

Типа стейты держать в процессах отдельно от процессов с ними работающими? Причем они должны быть еще и не связанными. Тоже решение, но местами это выглядит как оверинжиниринг.

Это то как работает let it crash с той целью с которой он был придуман. Что может упасть — то не хранит ценного состояния, что хранит ценное состояние — то отделено от падающего

надо подумать над этим

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

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

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

компромисс такой вот…

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