Ну или я не привык ещё.

так а смысл тогда получается если у тебя все ошибки под один верхний тип будут подведены? Это же тоже самое что сделать recover в конце с похожим Exception

идея в том, что в разных кусках кода у тебя могут быть разные ошибки твоём MonadError, ну или FunctorRaise

и в ключевых точках ты можешь явно их преобразовывать

и в некоторых отдельных точках ты можешь что-то вывести из этого типа

Например, статускоды и типы для сваггера, отличающиеся от 200

окей, но так же можно сделать по типу эксепшены в условном error handler. Но еще вопрос же в другом, если тебе в одном методе в for нужно заюзать два метода с разными ошибками - их нужно будет приводить или к верхнему тему или вставлять обработчик (если не хочешь приводить к верхнему типу)

если приводим к верхнему типу то мы тогда теряем конкретные типы ошибки - что получается - смысл тогда от either

если постоянно обрабатывать - тут получается вопрос удобства возникает

один раз окей, а если несколько

ты почему-то заранее представил ровно один способ работать с ошибками в типах - и это иерархия типов и EitherT

На самом деле, я говорю о другом коде, там нет приведения к верхнему типу и нет EitherT

мне тогда нужен пример - ровно один способ это тот о котором все пишут в статьях когда я гуглю future either

поэтому у меня и возник вопрос - все пишут, а кто его юзает

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

окей

есть какие-нибудь варианты вставить элемент в лист в нужное место красивее этого? def insertForkToList(tree: CodeTree, list: List[CodeTree]): List[CodeTree] = { def f(ct: CodeTree) = {some filter} (list.filter(f) :+ tree) ::: list.filterNot(f) }

list.partition(f) match { case (left, right) => left :: tree :: right }

не знаю насколько это "красивее")

можно так val (left, right) = list.partition(f) left :: tree :: right

Парни, а где java 9 то? Сегодня же релиз, не?

Интернеты молчат

http://www.java9countdown.xyz/

здесь салют

что, теперь правда можно val list = new ArrayList<String>(); ?

здесь салют

а на оракле 9 нету(

джава днище

list.partition(f) match { case (left, right) => left :: tree :: right }

спасибо)

джава днище

фи

а что, с девяткой скала норм, модули не мешают?

а что, с девяткой скала норм, модули не мешают?

Можно без модулей. Правда, их вообще выпилить хотели. Я с тех пор не следил.

а на оракле 9 нету(

http://www.oracle.com/technetwork/java/javase/downloads/index.html

Вроде есть

ага, вот только в этом часе появилась

я уже поставил, пробую)

а у yourkit раньше была personal license. теперь нет? https://www.yourkit.com/purchase/

http://www.oracle.com/technetwork/java/javase/downloads/index.html

А 32 бит билдов и нет.

Только 64 бит, хех.

А докер имедж на Алпаине будет?)

Вообще конечно зря 32 битную не оставили

по akka streams есть вопрос. может быть кто сталкивался - поделитель опытом. есть flow, который состоит из множества этапов. каждый этап может вернуть либо ошибку(но не кинуть исключение), либо результат. если один из этапов вернул ошибку - остальные этапы не нужно выполнять. все элементы должны дойти до конца flow. текущее решение - каждый этап Flow возвращает Either[MyError, Result]. на каждом этапе проверяем, если это Left - просто пробрасываем в следующий этап, никак не обрабатывая. В конечном счете становится несколько муторно, но в принципе терпимо. есть вариант описать через GraphDSL, где ошибки будут сразу кидаться в конец графа, минуя все этапы.

какие еще есть варианты, что реализовали может?

по akka streams есть вопрос. может быть кто сталкивался - поделитель опытом. есть flow, который состоит из множества этапов. каждый этап может вернуть либо ошибку(но не кинуть исключение), либо результат. если один из этапов вернул ошибку - остальные этапы не нужно выполнять. все элементы должны дойти до конца flow. текущее решение - каждый этап Flow возвращает Either[MyError, Result]. на каждом этапе проверяем, если это Left - просто пробрасываем в следующий этап, никак не обрабатывая. В конечном счете становится несколько муторно, но в принципе терпимо. есть вариант описать через GraphDSL, где ошибки будут сразу кидаться в конец графа, минуя все этапы.

решал двумя способами, первый способ - был такой же комбинировал с помощью операторов, вдохновлённых https://hackage.haskell.org/package/base-4.10.0.0/docs/Control-Arrow.html#t:ArrowChoice на коты, к несчастью, не могу дать ссылку, у них Choice бедноватый Но в общем суть в том, что простыми операторами Flow[A, B] или Flow[A, Either[E, B]] становятся Flow[Either[E, A], Either[E, B]], который уже встроенными способами композится

Второй вариант - написать собственных композеров для FanOutShape2, внутри которых merge

Первый больше понравился

Второй вариант - написать собственных композеров для FanOutShape2, внутри которых merge

примера не будет случайно? это уже на graphDSL нужно будет переходить, верно? или можно плоским Flow обойтись?

примера не будет случайно? это уже на graphDSL нужно будет переходить, верно? или можно плоским Flow обойтись?

один раз маленький кусок пишешь на graphDSL, потом в implicit class ы засовываешь коды, чтобы своим via дополнить

Господи, ну и мерзость.

Бота нельзя суммонить?

Бот не просек

пропустил

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

так что там было то?

спам для бородачей

и фоточка бороды в виде хелицер

У меня тут странное в sbt. В некоторых подпроектах добавление .settings(Defaults.coreDefaultSettings) выдает ошибку при запуске сбт: [error] References to undefined settings: [error] {.}/*:thisProjectRef from {.}/*:onLoadMessage ((sbt.Defaults) Defaults.scala:178) [error] Did you mean subproject1/*:thisProjectRef ? [error] {.}/*:thisProject from {.}/*:baseDirectory ((sbt.Defaults) Defaults.scala:1062) [error] Did you mean subproject2/*:thisProject ? [error] {.}/*:thisProject from {.}/*:name ((sbt.Defaults) Defaults.scala:176) [error] Did you mean subproject2/*:thisProject ?

подпроекты вроде бы точно такие же как остальные, но падает только в этих двух

непонятно даже в какую сторону копать. Я так понимаю проблема в том что > thisProject: Provides the Project associated with this scope (undefined at the global and build levels) > thisProjectRef: Provides the ProjectRef for the context (undefined at the global and build levels) но каким образом я мог поменять скоуп на global - непонятно

И еще странное поведение: inThisBuild(test in assembly := {}) не работает. А вот если руками в каждый сабпроект проставить это, то работает. При этом я никак сверху не накатываю нигде настроек ассембли дополнительных. Может быть так что autoplugin перетирает inThisBuild настройки?

решал двумя способами, первый способ - был такой же комбинировал с помощью операторов, вдохновлённых https://hackage.haskell.org/package/base-4.10.0.0/docs/Control-Arrow.html#t:ArrowChoice на коты, к несчастью, не могу дать ссылку, у них Choice бедноватый Но в общем суть в том, что простыми операторами Flow[A, B] или Flow[A, Either[E, B]] становятся Flow[Either[E, A], Either[E, B]], который уже встроенными способами композится

Можно посмотреть пример реализации первого способа? Там всё равно внутри флоу происходит проверка, левое или правое значение получено?

@odomontois так это, че там по поводу Future[Either]?

Щащащащаща

Вечерком

@odomontois так это, че там по поводу Future[Either]?

Ну я ещё так делаю, потому что явно лучше чем неявно т видно какие ошибки есть

EitherT облегчает жизнь, да

по akka streams есть вопрос. может быть кто сталкивался - поделитель опытом. есть flow, который состоит из множества этапов. каждый этап может вернуть либо ошибку(но не кинуть исключение), либо результат. если один из этапов вернул ошибку - остальные этапы не нужно выполнять. все элементы должны дойти до конца flow. текущее решение - каждый этап Flow возвращает Either[MyError, Result]. на каждом этапе проверяем, если это Left - просто пробрасываем в следующий этап, никак не обрабатывая. В конечном счете становится несколько муторно, но в принципе терпимо. есть вариант описать через GraphDSL, где ошибки будут сразу кидаться в конец графа, минуя все этапы.

да, только так. третьего способа мне не известно. первый или второй сильно зависит от домена. можно сделать свой маленький EitherFlow[T], который будет скрывать всю сложность. можно все в рукопашную, что тоже ок

@odomontois так это, че там по поводу Future[Either]?

Плюс ошибка не всегда исключение, глупо их кидать когда не надо.

тогда вопрос) Есть трейт Error и от от него два вида еррора. Потом у тебя есть метод который делаешь for и там вызывается два других метода - Future[Either[ErrorA, String]] и Future[Either[ErrorB, String]], когда ты делаешь flatMap с EitherT они у тебя подведутся к общему типу Error - ну и как тут видно какая именно ошибка там?

это тоже самое что хэндлить эксепшен общий

@odomontois так это, че там по поводу Future[Either]?

В общем, куски кода позже. Но идея такая. У тебя есть своя кастомная монадка, не какое-то говнонаслоение Eff или трансформеров, а совсем свой тир со сложным типом ошибки. Это не надтип всех ошибок, но из разнообразных ошибок в него есть морфизмы

Ты для каждого локального типа ошибки объявляешь FunctorRaise ( по новому котовьему словарю)

А в сервисах требуешь один какой-то конкретный

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

Но твоя эта суперошибка - это не свалка всего, она описывает все способы обработать ошибку в итоге и информацию, которая для этого тебе понадобится

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

но это я так понимаю речь не о Future[Either]

а о M[Either]

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

Не не, я никогда не испоганил бы свой продакшн каким-то нечитаемым стеком трансформеров

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

Речь идёт о чём-то типа final case class MyApp[+A]( Context => Task[Either[MyError, MySpecialResult[A]]])

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

допустим где все зависит от исходных параметров

давай допустим поговорим о доступе к базе где могут кидаться ошибки мол констрейт нарушен или допустим нету конекшена в базу

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

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

окей, то есть Future.failed все равно нужно обрабатывать

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

окей, то есть Future.failed все равно нужно обрабатывать

Да

окей, то есть Future.failed все равно нужно обрабатывать

ну это всегда придется, потому что ты не можешь же всё обвесить кастомными ошибками

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

Ничего не мешает. Но ничего не говорит о том, сделал ли ты это, учтена ли ошибка в результате, или всё ещё лежит в фейле

окей, то получается при вызове метода который возвращает Future[Either[A, B]] ты должен убедится что он раскроется в Future[B] , то есть ошибка будет обработана

тогда вопрос) Есть трейт Error и от от него два вида еррора. Потом у тебя есть метод который делаешь for и там вызывается два других метода - Future[Either[ErrorA, String]] и Future[Either[ErrorB, String]], когда ты делаешь flatMap с EitherT они у тебя подведутся к общему типу Error - ну и как тут видно какая именно ошибка там?

Делай для каждого слоя свой sealed class ошибки и когда вызываешь один слой из другого - приводи ошибки по своей логике

как правило такие штуки решаются через getOrElse - но таких случаев не много. Если юзер ввел неправильные данные - тебе полюбому нужно кинуть ошибку

Поэтому вполне возможно, что для некоторых ошибок ты возьмёшь и напишешь такой FunctorRaise, который будет просто возвращать Task.fail

Для некоторых не менее просто raise(MiscError(failText))

блин, но мне сложно все равно увидеть приемущество от этого механизма если тоже самое делается через throw во фьюче