willturnintofault يتم استدعاؤه أكثر من مرة ، مما يؤدي إلى تحطم

Question

في فئة فرعية NSManagedObject تنفيذي المتفوق على willTurnIntoFault يتم استدعاؤه مرتين عند التراجع عن بعض التعليمات البرمجية التي أنشأت في الأصل الكائن المعني. ينتج عن هذا حادث تحطم عند محاولة الانتعاش المزدوج لـ KVO على مسار رئيسي.

تقول مستندات Apple أن هذا هو المكان المناسب لعدم التسجيل لـ KVO.

القليل من السياق - تتضمن عملية التراجع إزالة العرض المقابل للنموذج من مراقبة الإشراف. يحتفظ العرض بنموذجه.

لذلك سؤالي هو: ما نوع أخطاء المبرمج التي يمكن أن تؤدي إلى willTurnIntoFault يتم استدعاؤه مرتين في فئة فرعية NSManagedObject?

ملاحظة: في السابق كنت أتجاوز dealloc في هذه الفئة ولكن أدركت ذلك منذ ذلك الحين ، لا ينصح بالفئات الفرعية من NSManagedObject. لقد نقلت هذا الرمز منذ ذلك الحين -didTurnIntoFault. أنا لا أتجاوز حاليًا أي طرق أخرى تقول مستندات Apple إنه يجب ألا تتغلب عليها.

Answer 1

يبدو أن المشكلة ناتجة عن طريقة Setter مخصصة كانت تقوم بإعداد/إزعاج قيم KVO من داخل WillturnIntofault.

Answer 2

من أجل الأجيال القادمة: واجهت نفس المشكلة. في حالتي كان لدي شيء أ مع وجود (إلى واحد) علاقة لكائن ب. متي أ تم حذفها بعلاقة عكسية أ تم تعيينه إلى null. هذا سبب ب'س observeValueOfKeyPath:ofObject:change:context الطريقة التي يجب الاحتجاج بها (حيث keypath كنت بعلاقة أ). لسوء الحظ ، فحصت هذه الطريقة خاصية أ, ، مما تسبب في صدع أ ليتم إلغاؤه (لاحظ أنه في هذه الحالة awakeFromFetch لا يتم الاتصال به-أفترض لأن الكائن لم يصل إلى حالة خطأ). وبالتالي قد أتلقى مكالمة ثانية willTurnIntoFault في وقت لاحق وسيحاول الكائن إلغاء التسجيل لـ KVO مرة أخرى ، مما أدى إلى تحطم-كما هو الحال في البروتوكول الاختياري.

بالنسبة لي كان الحل هو تغيير قاعدة الحذف لـ A to Cascade ، بحيث يتم حذف الكائن B عند حذف الكائن A و لإلغاء التسجيل لـ KVO في prepareForDeletion. هذا مهم لأن حذف أ سوف لا يزال يسبب بالعلاقة العكسية التي يجب ضبطها على لا شيء من قبل ب تم حذفه بالفعل.

لاحظ أن prepareForDeletion يتم استدعاء من قبل ولكن ليس بدلا من ذلك من willTurnIntoFault. وبالتالي ، إذا قمت بإلغاء التسجيل على KVO في كليهما ، فأنت بحاجة إلى الحفاظ على بعض الحالة للتأكد من أنك لم تكن مسجلة بالفعل.