это можно и одним классом сделать.

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

ну для мелких проектов так и есть))

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

ну давай что там для крупных?

в логах фильтровать? :)

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

я полностью за. но чо мы там снизим то? :)

разными классами эксепшенов

и это... ты сейчас говоришь с человеком, создававшим класс эксепшена на каждый чих :)

так что... вот

Время, которое наобходимо будет понять на то, что все таки случилось.

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

эти вещи даже в лог не идут. по крайней мере в моих проектах.

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

эти вещи даже в лог не идут. по крайней мере в моих проектах.

тогда есть хороший вариант: catch (Throwable $e) { ; }

)))

и это... ты сейчас говоришь с человеком, создававшим класс эксепшена на каждый чих :)

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

еще и быстрее раза в 3

плюсы DI я могу обьяснить

а вот с эксепшенами чот заминка вышла

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

я вот последнее время рассматриваю экспш как событие

у тебя же не возникает вопроса почему на кжадое событие свой листенер, а не 1 общий на всё что есть?

И вот тут ты можешь возразить, что у обраобтчика событий есть бизнесс или инфраструктурная логика какая то

Но у обраобтки ошибки она тоже должна быть.

А если ты для каждой ошибки просто крэшишь запрос и выводишь текст ошибки...то тут наверно ServiceError достаточно будет одного на весь проетк

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

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

на уровне Presentation да, это и будет одна ошибка типо PostDontPassControl - и у нее достаточно будет лишь описать причину

для любых других ошибок - другой вариант - Internal error юзеру и в лог.

но на уровне бизнесс логики это разные события

а предстваь будет 50 вариантов отказа: не достаточно баланса пост содержит порноматериалы юзер постил уже за эти сутки юзер забанен в определеннйо группе ....

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

Если база данных отвалится то у тебя какой эксепшн будет последним?

Если база данных отвалится то у тебя какой эксепшн будет последним?

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

а предстваь будет 50 вариантов отказа: не достаточно баланса пост содержит порноматериалы юзер постил уже за эти сутки юзер забанен в определеннйо группе ....

во. это уже интереснее. я и забыл про порнофильтр :))

намучался с ним в свое время

хотя все это кроме порно - это ошибки авторизации. не совсем логика.

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

по-хорошему стоит

да и порно... логики то не касается. но уже есть о чем подумать.

по-хорошему стоит

а почему?

я тоже всю жизнь оборачивал а сейчас задумался - а нафиг я это делал

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

вопрос поставлен некорректно

что значит любые в другой

а почему?

ну вроде как если принципу лисков следовать то нужно оборачивать

а то заебешься указывать что у тебя интерфейс бросает ошибку базы данных, редиса, мемкеша и т.д.

если у тебя ошибка типо UserHasNoPriviligiesToEditTable то конечно на более высоком уровне нужно создать CantSaveToDbError, а еще на более высоком CantSavePost

если у тебя ошибка типо UserHasNoPriviligiesToEditTable то конечно на более высоком уровне нужно создать CantSaveToDbError, а еще на более высоком CantSavePost

https://pastebin.com/zDj5vS8U

Ну эт точно неудачный пример на мой взгялд)

ну вот както так. да. а почему? мне снаружи там... вообще непонятно что делать с этими эксепшенами. единственное что я наверху знаю, что если эксепшен логики - показать юзеру мессаж. если другой - показать юзеру Inner exception и залогироватью

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

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

а как надо?

ну CantCreateTestException - уже выглядит верхом абстракции в моем понимании - т.е просто констатация факта

дальше уже некуда оборачивать его

я говорю - Http слою вообще пофиг на эти тонкости. Ему надо "если эксепшен логики - показать юзеру мессаж. если другой - показать юзеру Inner exception и залогировать"

+ ты все ошибки одним ловишь кэтчем, как то нехорошо...или их там много но они все унаследованы от CantCreateTestException?

я говорю - Http слою вообще пофиг на эти тонкости. Ему надо "если эксепшен логики - показать юзеру мессаж. если другой - показать юзеру Inner exception и залогировать"

но работа с HTTP это чисто Presentation

тут я согласился что можно просто 1 erorr на все кидать

а какие другие случаи? если консоли вызывать, там ровно тоже самое.

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

так консоль тоже представление

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

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

это service layer

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

не в глубине, а в логике. там где база упала - будут свои эксепшены.

логика в моем понимании и есть самая глубина)

т.к я так вижу мир

ну давай допустим, что у нас нет отдельного доменного слоя пока. все действия делаются прямо в service layer

всегда когда я вижу фразу "Domain services" меня воротит :)

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

ну давай допустим, что у нас нет отдельного доменного слоя пока. все действия делаются прямо в service layer

ну упрощения архитектуру здесь играют на твою позицию)) но допустим...тогда нам все равно нужно разделить экпшн приложения(сервисов) от ошибок пользователю, чтобы инкапсулирвоать поведение и состояние ситемы. Т.е чтобы пользователь не видел `column user not found' а видел сообщение что база пока недоступна

мне так кажется

ну посмотрим может еще кто выскажется

есть че почитать/посмотреть/повникать на тему from procedure code to oop? а то у меня неправильная маничка делать сначала классами в процедурном стиле, а потом переписывать.

начал читать Брайана Мейрса "Почувствуй класс", по описанию вроде то что тебе нужно

Eiffel. прикона

начал читать Брайана Мейрса "Почувствуй класс", по описанию вроде то что тебе нужно

я бы гради бутча порекомендовал)

мэйрс странный и мне его идеи больше процедурщину напоминают но пофигу

всеравно почитать его стоит

эванс унылый а не сложный

ну обычно не осиливают потому что скучно

программист-некрофил любил писать на ada

я бы гради бутча порекомендовал)

да, лежит в отложеных на чтение) а Брайан типа автор eiffel и программирования на публичных контрактах (как написано в книге)

ну с идеями DbC ознакомиться стоит, конечно. Но не надо зацикливаться на мэйерсе. Это человек которого все цитируюют и никто не читал)

самая норм книжка по ооп для вхождения это от HeadFirst

половина принципов солид ему принадлежит если что. Боб даже не притворяется что сам выдумал

ну с идеями DbC ознакомиться стоит, конечно. Но не надо зацикливаться на мэйерсе. Это человек которого все цитируюют и никто не читал)

К любой идее не стоит относиться как к канону при изучении)

у них там 1 про паттерны а другая про проектирвоание но они пересекаются

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

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