AB
это два разных пути
в многих либах есть и encode и encode!
первый даст {:ok, blabla} or {:error, reason},
второй в чистом виде blabla или экзепшен
Size: a a a
2019 July 14
AB
первый вариант чтобы программировать в railway стиле
AB
второй чтобы pipe'ы строить
AB
V
За статью спасибо. А в чём разница между railway- и pipe- стилями?
V
И вопрос больше про конкретный кейс - валидацию аргумента по регулярке. Как это обычно делается? Через guard? Через if-конструкцию в начале метода? Через проверку по регулярке в начале метода с бросанием эксепшна?
AB
ну если ты какую-то библиотеку делаешь, которая, к примеру, енкодит что-то, и это в pipe часто используется, то через exception
AB
хотя, на самом деле часто в библиотеках есть и то и другое
ŹR
Зависит от «уровня» аргумента. Если это low level то можно exception.
Если бизнес логика - то error tuple
Если бизнес логика - то error tuple
V
Понятно, т.е. эксепшны в целом приемлимы.
ŹR
Exception это exception
ŹR
Если тебе пользователь прислал из поля email строчку без @ - это не exception
ŹR
Exception это когда из базы данных из integer поля пришла строка
SZ
Подскажите пожалуйста почему parent супервайзер оно крэшится после трех рестартов child супервайзера
https://gist.github.com/sigmaray/f7f96624ca2a2f44d60a953714471bf5
https://gist.github.com/sigmaray/f7f96624ca2a2f44d60a953714471bf5
SZ
try-catch я могу написать, но не хочу, хочу попробовать “Let it fail”
SZ
Запускаю через mix run priv/repo/fetcher.exs
Знаю что лучше прописывать в application, но тоже не хочу. Хочу попробовать на escript писать.
Знаю что лучше прописывать в application, но тоже не хочу. Хочу попробовать на escript писать.
SZ
В идеале хотелось бы чтобы оно бесконечно перезапускалось, а не сдыхало после трех перезапусков. Чего ж оно сдыхает, не понимаю
ŹR
Если падает слишком часто - тогда супервизор умирает
ŹR
3 раза за 5 секунд по дефолту вроде