ну надо подумать над именованием, чтобы не было так жутко

сам подход жутковат, а не именование

так ты на телефоне лучше напиши)

сам подход жутковат, а не именование

я встречаю такое не первый раз, так что не настолько и жутко

так ты на телефоне лучше напиши)

как минимум неоднозначный $user :) но это так, придирки

формально, с исключениями дела обстоят так же. Тонна всяких типов, все дела. Но оно как-то всё проще смотрится, имхо

возврат объекта как результата тоже имеет право на жизнь правда, колво бойлерплейт-кода будет немалым

формально, с исключениями дела обстоят так же. Тонна всяких типов, все дела. Но оно как-то всё проще смотрится, имхо

тут семантика (холивар о ней, юху) я вполне согласен с Евгением в том, что исключения в этом случае - микроскоп и гвозди

хотя вопрос очень спорный

тут семантика (холивар о ней, юху) я вполне согласен с Евгением в том, что исключения в этом случае - микроскоп и гвозди

в жопу семантику) крайне мутное понятие

не, я такое люблю, не зря сегодня закидывал ребят во vue.js чятике про перевод слова "props"

не, я такое люблю, не зря сегодня закидывал ребят во vue.js чятике про перевод слова "props"

логичней его arguments как то назвать ?

в джаве есть разделение на фатал эрроры и исключения?

хотя это же js

пойду дальше исключения плодить)

в джаве есть разделение на фатал эрроры и исключения?

там есть RuntimeException

логичней его arguments как то назвать ?

ну, это ведь по мотивам реакта заделано

и не runtime

там есть RuntimeException

оно не ловится?

я про аналогию с пхпшными эррорами

ну типо может не ловиться если рантайм

чуть чуть отличается

если исключение не runtime ты обязан его ловить

или ничего не соберется

ага, уловил

если исключение runtime то похуй вроде и код соберется

можно ловить все рантаймы в одном месте

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

А зачем вообще пытаться закрыть контракт при открытых инвойсах?

Ничего личного, но ухадите со своей джавой.

А зачем вообще пытаться закрыть контракт при открытых инвойсах?

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

А зачем вообще пытаться закрыть контракт при открытых инвойсах?

имхо для закрытия контракта как раз исключение норм идея наверно

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

типо ты такой контракт->закройся()

а он такой пышь, не могу хозяина есть открытые инвойсы

ты типо до закрытия контракта должен проверить ручками инвойсы

и по закрывать их

и только потом закрывать контракт

инвойсы закрываются не изнутри)

ну точнее это отдельное действие

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

ну ты типо как то так написать должен

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

ну а почему нет? можно что-то типа ActiveUser implements User, StaleUser implements User. у второго есть метод closeContract() у первого - нет. UserRepo.getStaleUsers().map(user => user.closeContract())

foreach($contract->getInvoices() as $invoice) { $invoice->close(); } $contract->close();

foreach($contract->getInvoices() as $invoice) { $invoice->close(); } $contract->close();

не, не то

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

или сделать

инвойс должен быть оплачен

точнее, если он оплачен - он закрыт

можно так сказать

$contract->closeWithInvoice() и тут уже в начале инвойсы находятся и закрываются потом инвойс

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

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

если инвойс без оплаты низя закрывать

ну тогда логично тут исключение кинуть

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

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

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

А кто как не инвойс будет проверять свой статус?

А кто как не инвойс будет проверять свой статус?

когда во фронт отдается инвойс

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

и чтобы рядом с ним кнопка была закрыть

смотри

блин только недавно на эту тему видос смотрел

но забыл как называется

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

варианты: 1. исключение 2. возврат bool 3. возврат класса (по сути, расширенное 2) 4. монады (тоже близко к 2 и 3)

так как нам пришла команда закрыть то что нельзя закрывать

ну и 5. вынести проверку наружу

блин только недавно на эту тему видос смотрел

Почему ты так сильно разбиваешь сущности?

имхо должно быть 1 и 5

в бэкенде должно быть исключение

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

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

Сильно

надежно я бы сказал

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

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

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

Ты заказчику объясни это Он хочет кнопку и ошибку

хочет выводить ее без отправки в бэк

фактически все это одно и то же мы знаем, что там может произойти ошибка (знаем потому, что закрываться контракт может и автоматически по крону) исключение - мы ловим его в catch буль - проверяем ифом объект ответа - проверяем класс или содержимое монада - хз, я достаточно еще не вник, но в версии с php, как понимаю, близко к объекту ответа вынести проверку наружу - получаем тупо тот же if и обработку ошибки

суть остается одной и той же

еще раз

Почему ты так сильно разбиваешь сущности?

а почему нет? юзеры разные, с ними можно делать разные вещи

у тебя есть бэкенд и пользователи (фронтенд и крон)

пользователи не должны закрывать контракты с открытыми инвойсами

тут с я тобой соглашусь

если такое происходит для бэкенда это исключение или ошибка (тут сам решай)

кнопку спрятать не проблема

пользователи должны иметь возможность проверить

контракт на открытые счета

типо /contract/34/invoices?isOpen=true

и перед закрытием проверять

если какой то распиздяй фронтендер или кто то забыл добавить эту проверку

то ничего фатального и неисправимого не произойдет

логер бэкенда залогирует исключение (они же у вас логируются?)

пользователь сообщит об ошибке в трекер (в идеальном случае типо не могу закрыть инвойс такой то)

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

это даже ошибкой назвать сложно.

нормальный такой себе workflow

ну типо код ответ ошибка (не завершилось успешно) и message

ненене

смотри