Ну тип длина строки какого-то названия не должна парить домен, валидность к примеру мыла тоже.

валидность мыла может парить домен и это хорошо выражается типами и всякими VO типа Email

Стоп я на всякий случай уточню. Клиент переодически спрашивает о том есть ли что для него аосредством нового запроса. Типо ддосит. Мы про одно и тоже говорим?

тебе нужен просто полинг либо поставить какой centrifugo и не ебать голову

то что ты описал - это просто полинг. Лонг полинг это когда ты подключаешься к серверу и соединение держится какое-то время (например 30 секунд) и если у сервера чего есть для клиента - выплевывается. А если нет - тайпаут и реконнект.

Да я так и представлял себк лонг полинг. Что конект держиться и ответ шлет сервер клиенту. А то что я описал я думал это говнище которое не используют уже лет 10 со времен как js на сайтах в таймере опрашивал сервер. И точто это просто полинг не знал. Спасибо, пойду гуглить)

валидность мыла может парить домен и это хорошо выражается типами и всякими VO типа Email

Да но может и не парить. Тогда что мыло валидно проверяет кто-то другой, а то что к примеру мыло может быть только от mail.com или google это домен. Ну правда опять зависит от контекста. Но я имел ввиду, что есть проверки которые домена не касаются

Верно?

тебе нужен просто полинг либо поставить какой centrifugo и не ебать голову

Хз что за centrifugo погуглю пойду. А так у меня в несколько потоков куча систем будет ебать мой сервер.

Да я так и представлял себк лонг полинг. Что конект держиться и ответ шлет сервер клиенту. А то что я описал я думал это говнище которое не используют уже лет 10 со времен как js на сайтах в таймере опрашивал сервер. И точто это просто полинг не знал. Спасибо, пойду гуглить)

то что ты описал - просто полинг, не лонг. Короткий полинг если хочешь. Но сегодня никто не запрещает тебе взять ту же центрифугу и получить сокеты дешево и без СМС

Да но может и не парить. Тогда что мыло валидно проверяет кто-то другой, а то что к примеру мыло может быть только от mail.com или google это домен. Ну правда опять зависит от контекста. Но я имел ввиду, что есть проверки которые домена не касаются

ну так базу email-ы тож не парят. И вообще никог тогда не парит.

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

то что ты описал - просто полинг, не лонг. Короткий полинг если хочешь. Но сегодня никто не запрещает тебе взять ту же центрифугу и получить сокеты дешево и без СМС

У меня межсервирное взаимодействие. Клиенты мои этт другие сервера.

У меня межсервирное взаимодействие. Клиенты мои этт другие сервера.

тогда тебе нужны вэбхуки

это надежнее

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

так типа будет клево и удобно и не надо никого бомбить

тогда тебе нужны вэбхуки

Да не) там все сложней. Я работаю по протоколу готовому и он диктует правила

Это soap сервис который реализует протокол общения описаный в xsd

ну так базу email-ы тож не парят. И вообще никог тогда не парит.

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

Ктонибудь работал со SMEV протоколом?)

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

и с этим прекрасно справляются VO.

Ктонибудь работал со SMEV протоколом?)

ебучие госуслуги?

и с этим прекрасно справляются VO.

Типа при создании VO email идет эта проверка?

ебучие госуслуги?

?

Типа при создании VO email идет эта проверка?

да. У тебя там где надо email все контракты просто принимают не string а Email. И ассампшен что этот объект не может содержать невалидный email.

Ну либо Email<Valid>|Email<Unchecked> и тип может меняться

Если может где-то неважно валидный ли он, а где-то важно

Ну либо Email<Valid>|Email<Unchecked> и тип может меняться

ну это разумеется в языках которые умеют в такие вещи как алгебраические типы, да?)

пойду смотреть на PHP и плакать

ну это разумеется в языках которые умеют в такие вещи как алгебраические типы, да?)

Кст что за языки?)

ну это разумеется в языках которые умеют в такие вещи как алгебраические типы, да?)

Ну в пыхе нельзя, да

Java 152?

Кст что за языки?)

F#, Scala, Clojure, OCaml, Haskell

да. У тебя там где надо email все контракты просто принимают не string а Email. И ассампшен что этот объект не может содержать невалидный email.

а вот кстати, что если проверка валидности VO тяжёлая и нужно сползать в какую-нибудь бд или на диск, пихать зависимость от объектов получающих данные для валидации?

а вот кстати, что если проверка валидности VO тяжёлая и нужно сползать в какую-нибудь бд или на диск, пихать зависимость от объектов получающих данные для валидации?

фабрики

фабрики

но тут надо типа запретить как-то объект напрямую создавать =\ Хотя может конвеншенами обойтись нормально получится =\

а вот кстати, что если проверка валидности VO тяжёлая и нужно сползать в какую-нибудь бд или на диск, пихать зависимость от объектов получающих данные для валидации?

А стоит ли вообще при создании и валидации VO лезть за стейтом? VO ли это?

Если проверки зависят от стейта?

но тут надо типа запретить как-то объект напрямую создавать =\ Хотя может конвеншенами обойтись нормально получится =\

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

А стоит ли вообще при создании и валидации VO лезть за стейтом? VO ли это?

лазить за стэйтом будет штука пораждающая VO. Ассампшен что у этой штуки этот стэйт есть.

короч, опять же может хватит коней в вакууме обсуждать? Лучше придумай мне кейс при котором мне надо что-то сложно валидировать на что бизнесу в целом насрать

что бы можно было честно flow of control мутить

почему на ивентах честно, а на эксепшенах - нет?

почему на ивентах честно, а на эксепшенах - нет?

потому что мутить control flow на исключениях грешно)

Ну а мне интересно - почему

что такого плохого в исключениях и как это решается ивентами

справедливости ради - исключения плохо только тогда, когда ты кидаешь исключение с мыслью что кто-то его обязательно поймает. Как эдакое сообщение которое идет в разрез с обычным потоком управления кодом. Как goto. А чем плохи goto - читать тут: http://david.tribble.com/text/goto.html

справедливости ради - исключения плохо только тогда, когда ты кидаешь исключение с мыслью что кто-то его обязательно поймает. Как эдакое сообщение которое идет в разрез с обычным потоком управления кодом. Как goto. А чем плохи goto - читать тут: http://david.tribble.com/text/goto.html

Но ведь ивенты точно так же будут работать, разве нет?

Но ведь ивенты точно так же будут работать, разве нет?

ну я про доменные ивенты - они не такие шустрые и не работают как goto (не вылазят по стэку вызовов)

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

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

но оч легко поддаться на всякие плохие штуки

О, спасибо, это рассуждение порядок в голове в этом уголке навело)

Мне ваш диалог напомнил историю которую недавно у лида услышал. На собесе пришел чувак и с гордостью продемонстрирвоал свой фреймворк с "убийцей сервис контейнера". Суть в том что он ВСЕ сервисы наследовал от Exception и в случае когда ему нужен какой то сервер он просто делал Throw, отлавливал его и юзал. Из минусов своего фреймворка он указал то, что нужно следить за тем что все сервисы отлавливались, т.к если взять сервис и не обернуть в кэтч то все упадет

кидок в сторону контейнера какой-то

Мне ваш диалог напомнил историю которую недавно у лида услышал. На собесе пришел чувак и с гордостью продемонстрирвоал свой фреймворк с "убийцей сервис контейнера". Суть в том что он ВСЕ сервисы наследовал от Exception и в случае когда ему нужен какой то сервер он просто делал Throw, отлавливал его и юзал. Из минусов своего фреймворка он указал то, что нужно следить за тем что все сервисы отлавливались, т.к если взять сервис и не обернуть в кэтч то все упадет

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

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

тут соглашусь

на хабре был один наркоман с которым мне нравилось спорить - у него async/await на исключениях и норм

работало без всех этих ваших сложностей с генераторами

на хабре был один наркоман с которым мне нравилось спорить - у него async/await на исключениях и норм

Т.е?

Т.е?

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

но это работало

А пример не накинешь?

там вся магия под копотом и я реально не помню как он это делал

Потому как у меня 2 варианта реализации того что ты сказал

на хабре был один наркоман с которым мне нравилось спорить - у него async/await на исключениях и норм

а как он возвращал флоу выполнения обратно О.о

я хз, честно

просто делюсь что люди творят под веществами

const a = throw asyncF() все хорошо, но обратно ж не вернуться

А, все таки это

const a = throw asyncF() все хорошо, но обратно ж не вернуться

А почему не вернутся?

а как?

Именно в выполнение без .catch?

да

Сек

ну дальше же этот a заюзать хочется с каким-то значением)

С await у тебя будет тот же exception

Только само исключение будет обернуто в промис

Но выполнение дальше не пройдет если не обработаешь

если я throw заменю на await?

нет же, в случае генераторов я могу продолжить вычисление генератора

gen.next()

и даже значение прокинуть

или exception

а как в случае эксепшена мне значение обратно прокинуть

а как в случае эксепшена мне значение обратно прокинуть

Ты имеешь в виду asyncThrow.catch(value => value / это?)

Я не юзал генераторы, пардоньте (юзал, но не помню)

f = async () => { x = await foo() }

как без генераторов в x вернется значение foo ?

А что не так? ?

const f = () => { const x = throw foo(); console.log(x) } и дальще runAsync(f)

как должен быть реализован этот runAsync?

Он должен обработать exception

const runAsync = f => { try { f() } catch(e) { // wtf should be here?? } }

дальше?)

Тебе x нужен?)

ну да, мне надо чтобы f отработал

предположим, что foo такой: const foo = () => Promise.resolve(20)

по итогу запуска f в консоль должно вывестись 20

Окей. А как ты себе это представляешь?) Ты кидаешь исключение и хочешь, чтобы код ниже исключения был выполнен