Size: a a a

2021 April 01

E

Evgeniy in phpGeeks
Killer 🔪
такая проблема

есть массив [1, 2, 3, 4]
нужно разделить его на части по двум значением типо [[1,2], [3,4]]

как это делать.? башка уже не работает
источник

ДЩ

Дмитрий Щербаков... in phpGeeks
Павел Г.
Не должен он делать свое исключение, есть интерфейс с экзепшенами. Это как "А вдруг автор захочет другой REsultClass вернуть"
Не изучал ещё мейлеры, но допустим смс шлюзы, каждое апи может возвращать разные ошибки, я в интерфейсе сделаю исключения под один шлюз, а потом реализация другого шлюза а там больше ошибок
источник

ПГ

Павел Г. in phpGeeks
Дмитрий Щербаков
Не изучал ещё мейлеры, но допустим смс шлюзы, каждое апи может возвращать разные ошибки, я в интерфейсе сделаю исключения под один шлюз, а потом реализация другого шлюза а там больше ошибок
А причем тут ошибки шлюзов. У тебя будет свой интерфейс(тут кстати уже не вопрос исключений и результатов), который будет перерабатывать их ошибкив  свои
источник

ПГ

Павел Г. in phpGeeks
У тебя в любом случае будет адаптер со своими ошибками, иначе ты не сможешь ругие шлюза подключать динамически
источник

ПГ

Павел Г. in phpGeeks
Да и не нужны тебе все их ошибки, максимум в логировании
источник

ДЩ

Дмитрий Щербаков... in phpGeeks
Ну типа а вдруг ни один из исключения не подходит, если только всегда в интерфейсе последним писать RuntimeException
источник

E

Evgeniy in phpGeeks
Дмитрий Щербаков
Не изучал ещё мейлеры, но допустим смс шлюзы, каждое апи может возвращать разные ошибки, я в интерфейсе сделаю исключения под один шлюз, а потом реализация другого шлюза а там больше ошибок
Делаю базовый класс для таких исключений, который так же соответствует своему интерфейсу. Хочешь добавить свое исключение - наследуйся, соблюдай интерфейс исключения.
источник

ДЩ

Дмитрий Щербаков... in phpGeeks
Evgeniy
Делаю базовый класс для таких исключений, который так же соответствует своему интерфейсу. Хочешь добавить свое исключение - наследуйся, соблюдай интерфейс исключения.
Или так да
источник

ПГ

Павел Г. in phpGeeks
Дмитрий Щербаков
Ну типа а вдруг ни один из исключения не подходит, если только всегда в интерфейсе последним писать RuntimeException
В данном случае скорее всего нужен как раз result, так как возможно будет разная логика. Или же один MailerException с разными кодами- и все, зачем 1000 исключений
источник

ПГ

Павел Г. in phpGeeks
Конечно можно и 1000, если они реально нужны
источник

K🔪

Killer 🔪 in phpGeeks
оо спасибо
источник

ПГ

Павел Г. in phpGeeks
Короче имхо. ResultClass специфичная вещь, ну или надо писать в этой архитектуре всё. Остальное покрывается исключениями легко
источник

ПГ

Павел Г. in phpGeeks
Evgeniy
Делаю базовый класс для таких исключений, который так же соответствует своему интерфейсу. Хочешь добавить свое исключение - наследуйся, соблюдай интерфейс исключения.
Тут момент в том, что смысла в этом нет. Сервисы, которые будут работать со шлюзом работают именно с интерфйесом. И пихать в новый шлюз кастомное исключение, которое под каким то интерфейсом, зачем?
источник

ПГ

Павел Г. in phpGeeks
Короче разваливает несколько абстракцию
источник

ДЩ

Дмитрий Щербаков... in phpGeeks
Ну я согласен что исключения в докблоке интерфейса удобен по меньшей мере тем что сразу видно точный список ошибок, а ещё их можно легко прокидывать наверх
источник

ДЩ

Дмитрий Щербаков... in phpGeeks
Спасибо
источник

ПГ

Павел Г. in phpGeeks
Дмитрий Щербаков
Ну я согласен что исключения в докблоке интерфейса удобен по меньшей мере тем что сразу видно точный список ошибок, а ещё их можно легко прокидывать наверх
И IDE при должном использовании подсказывает что "дорогой, вы не поймали нигде экзепшен"
источник

ПГ

Павел Г. in phpGeeks
Правда с этим тоже какие то заморочки есть)
источник

ДЩ

Дмитрий Щербаков... in phpGeeks
Глобальный хендлер поймает
источник

E

Evgeniy in phpGeeks
Павел Г.
Тут момент в том, что смысла в этом нет. Сервисы, которые будут работать со шлюзом работают именно с интерфйесом. И пихать в новый шлюз кастомное исключение, которое под каким то интерфейсом, зачем?
Допустим так. Есть возможность авторизоваться через соцсети. Согласен, у каждой соцсети будет своя реализация библиотеки. Поднимемся уровнем повыше. В приложении у нас скорее всего будет фабрика, в которую мы передадим название соцсети и эта фабрика вернёт нам обёртку, которая умеет работать с конкретной библиотекой. Обёртка будет соответствовать интерфейсу и будет уметь обрабатывать ошибки конкретной соцсети: логировать их и передавать на следующий уровень. Именно в этом месте множество оберток и будут давать эти исключения. ( Соответствующие общему предку и интерфейсу) и наше приложение поймет, что что-то пошло не так именно с авторизацией через соцсети.
источник