Здравствуйте, IT, Вы писали:

IT>Здравствуйте, microuser, Вы писали:

M>>Так в данном примере вообще ничего искать не нужно, т.к. при использовании DI экземпляр Bar будет создаваться контейнером и все его зависимости будут так же создаваться контейнером, соответственно нужно посмотреть только код конфигурации этого контейнера.

IT>И что я там увижу? Список имён классов?

M>>Кроме того современные контейнеры никогда к такой ситуации не приведут, т.к. Bar не сможет быть равен null, будет ошибка при попытке создания Foo о том что не удалось разрешить зависимость Boo и там же в стек трейсе будет видно почему не удалось.

IT>По-поводу умения абстрагироваться я уже выше отписал.

Я же отвечал на конкретный код, который ты привел.

Хорошо, давай модифицируем пример:

class Foo
{
public Foo(Bar b)
{
if (b.Atata == null)
throw ...
}
}

В данном случае при ошибке у нас будет стек трейс в котором будет прекрасно видна последовательность вызовов, поэтому ходить по конструкторам и изучать кто кого вызывал уже будет не нужно.
Предположим что стек трейса у нас нет, но мы знаем что ошибка была и хотим понять как так получилось что Atata == null. Тогда нам нужно нажать Shift+F12 на свойстве Atata, но не на конструкторе. Вот это реальный кейс который часто встречается на практике.

Просто кейс что при использовании DI в конструктор передали null невозможен в принципе, тут нужен другой пример.