Невозможно без больших усилий дублировать функциональные возможности отладчика, dtrace и / или различных других инструментов, которые делают именно такие вещи. Это удивительно зависит от архитектуры и изобилует особыми случаями и ситуациями, которые не работают.
Вы, конечно, никогда не захотите делать это в рабочем коде. Для отладки достаточно инструментов, которые делают это в достаточном количестве контекстов, поэтому в этом нет необходимости.
Что вы пытаетесь сделать?
В основном я использую КВО, и если КВО
метод вызван из другого
метод, который является IBAction я не
что это делать, что было бы нормально
сделать иначе, это бы зациклилось
(относится к моему предыдущему вопросу).
На этом пути лежит безумие. Это полностью нарушает инкапсуляцию, чтобы иметь метод, на выполнение которого влияет вызывающая сторона, не являясь своего рода явным аргументом или неявной конфигурацией, указывающей, что поведение должно измениться.
Если вы попали в бесконечный цикл, то я бы предложил пересмотреть всю вашу архитектуру.
В частности, когда срабатывает уведомление KVO, оно почти никогда не должно инициировать уведомление KVO об одном и том же свойстве, прямо или косвенно. В крайне редком случае, когда это неизбежно, вы должны убедиться, что вы делаете триггеры KVO вручную, используя -willChangeValueForKey: и -didChangeValueForKey: условно.
В основном, просто чтобы объяснить, я
наблюдая свойство основных данных и тому
метод, который вызывается, когда
изменение свойств вызывает другой метод
(IBAction), но в этом IBAction это
добавляет объекты Core Data, которые запускаются
метод КВО, который запускает
IBAction и пр. Вот почему я
пытался выяснить, где
метод был вызван, чтобы я мог остановиться
этот бесконечный цикл
Другими словами, у вас есть изменение уровня модели, которое затем вызывает метод на интерфейсе между уровнем представления и уровнем управления (метод IBAction), который, что неудивительно, вызывает другое изменение уровня модели, которое затем сходит с рельсов. ....
Как только ваш наблюдатель сработает, и в результате вам нужно будет внести изменения в модель, вы должны сохранить всю логику изменений в слое модели. В конце концов, это ваша модель, и она должна обладать умом правильно применять изменения.
Что никогда не должно происходить, так это то, что управляющий слой или слой представления вызывает изменения в модели в ответ на изменение модели. Изменения в модели - данных - со слоя управления / представления должны происходить только в ответ на действия пользователя или какое-либо внешнее событие (таймер, случайность).