Dependency Injection Container, попробовал на практике - не понял смысла?

Спасибо большое! Стало более понятно.

например некий провайдер более чем в 1 месте или некий Sender в 20 местах по всему приложению. И упростить к ним доступ.

А вы не знаете репозитории на гитхабе или где можно посмотреть примеры, почитать код, чтобы понять, что и когда используется, и посмотреть на реальном примере ? Или если возможно смоделировать такой пример, где будет понятно преимущество контейнера и вариант без него - буду очень благодарен!

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

Одно из преимуществ - автоматическое внедрение зависимостей.

Это обязательное условие для контейнеров?

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

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

Но вы можете упростить, и вынести инициализацию контейнера в абстракцию — в некий класс App/Kernel и там это делать, а в точке входа инициализировать не контейнер раз за разом, а именно конкретное приложение.

Будьте добры, пример пожалуйста. Не совсем представляю, как я могу в классе азполнить контейнер сервисами, сконфигурировать их и что дальше? Метод класса должен вернуть контейнер ? Или как ?

GuzzleHttp, как записать информацию дебага в переменную?

Спасибо большое!

Если данные не превысят 2Мб, они как любая переменная будут находится в оперативной памяти

Вы наверное спутали с php://tmp.

В этом случае все норм будет?
Т.е. не будут ли случаи, когда я записываю данные в php://memory и не успел их считать еще оттуда, какая-то другая библиотека окажется, что тоже туда что-то запишет - в этом случае накладок не будет? Или при инициализации, у каждого свой поток?

Как правильно организовать уровни исключений и логирование?

dmitriy, понял, спасибо большое за объяснение!

Как правильно организовать уровни исключений и логирование?

dmitriy, спасибо большое! Так понятнее стало.

в моем примере ни разу не применил swicth-case не понимаю и зачем он вам

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

try{
       ...
   }
   catch(ClassException1 $ex)

   }
   catch(ClassException3 $ex)

   }
   и т.д.

Насколько я понял, необработанные исключения можно отлавливать через set_exception_handler.

В какой момент мне записывать в лог?

в момент ловли исключения

У меня в голове такое представление (не знаю, можно ли делать так, и хорошая ли это практика):

создаем основной класс исключений, и в нем переопределяем конструктор, в котором будут данные из метода getMessage() добавляться в лог. Также создать доп. метод, в котором при необходимости можно будет передать другое сообщение для лога ( если не устраивает формат сообщения из getMessage() ).

Также хотелось бы завести 3 интерфейса, как писал в вопросе

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

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

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

и в зависимости от того, какой интерфейс имплементируется, появляется у класса исключения те возможности, которые описал выше (логирование из конструктора и доп. метод).

Только как это связать все, чтобы была грамотная архитектура - не знаю.

Как правильно организовать уровни исключений и логирование?

Спасибо! Но мне не понятен такой момент:

Например разрабатываю некий функционал интеграции с 1с, в процессе разработки можен возникать множество Исключительных ситуаций.

Например:
1. исключения, которые не требуют обязательной обработки.
2. исключения, которые нужно только обработать
3. исключения, при возникновении которых нужно обязательно сообщить администратору - добавить инфу в лог. (Не важно обработано исключение или нет)

С первыми двумя пунктами, мне немного понятно как быть. А вот с третьим непонятно, а именно:

В какой момент мне записывать в лог?

Если в момент, когда выбрасываю исключение?

Это нужно делать перед throw new Exception, или нужно в моем классе Exception реализовать методы добавления в лог в зависимости от того, како интерфейс имплементирую (UnloggedInterface, PreloggedInterface и т.д.)?

А как быть с исключениями, которые не обработал?

Если весь функционал обернуть в try - catche, то мне там придется десятки swicth-case перебирать классы экзепшином, чтобы понимать, с каким исключением что делать..

Удалить белый цвет и его оттенки с помощью PHP?

Посмотри ответ ниже. Лучше брать (r + g + b) / 3