اكتشاف ما تسبب في عودة ()

Question

كيف يمكنني معرفة ما الذي تسبب في عودة () للعودة الخاطئة؟

أنا لا أسأل عن النهج المؤكد ، ودائما صحيح ، ولكن عن شيء للمساعدة في عملية التنمية. حاليًا يجب أن أخطو إلى مكالمات متساوية () (عادةً شجرة منها) حتى يكون أحدها خطأ ، ثم خطوة إلى ذلك ، غثيان م.

فكرت في استخدام الرسم البياني للكائن ، وإخراجه بـ XML ومقارنة الكائنين. ومع ذلك ، يتطلب XMLencoder منشئًا افتراضيًا ، لا يتطلب JIBX مسبقًا ، ولا يتم استخدام واجهة برمجة تطبيقات X-tream و Simple في مشروعي. لا مانع من نسخ فصل واحد ، أو حتى حزمة ، في منطقة الاختبار الخاصة بي واستخدامها هناك ، ولكن استيراد جرة كاملة لهذا لن يحدث.

لقد فكرت أيضًا في بناء رسم بياني للكائن بنفسي ، وقد لا أزال أفعل ذلك ، لكنني أكره أن أبدأ في التعامل مع حالات خاصة (مجموعات مرتبة ، مجموعات غير مرتبة ، خرائط ...)

أي فكرة عن كيفية القيام بذلك؟

تحرير: أعرف أن إضافة الجرار هي الطريقة العادية لفعل الأشياء. أعلم أن الجرار هي وحدات قابلة لإعادة الاستخدام. ومع ذلك ، فإن البيروقراطية اللازمة (في مشروعي) لهذا لا يبرر النتائج - سأستمر في تصحيح الأخطاء والدخول.

Answer 1

من المفترض أنها ليست مقارنة للرسم البياني الكامل ... ما لم تتضمن متساوية كل خاصية في كل فصل ... (يمكنك المحاولة == :))

محاولة مطابقات هامكريست - يمكنك تكوين كل مطابقة في مطابقة "All of":

Matcher<MyClass> matcher = CoreMatchers.allOf(
  HasPropertyWithValue.hasProperty("myField1", getMyField1()),
  HasPropertyWithValue.hasProperty("myField2", getMyField2()));
if (!matcher.matches(obj)){
  System.out.println(matcher.describeFailure(obj));
  return false;
}
return true;

سيقول أشياء مثل: "من المتوقع أن يكون لـ MyField1 قيمة" القيمة "ولكنها كانت" قيمة مختلفة ""

بالطبع يمكنك ضمن المصانع الثابتة. هذا أثقل قليلاً من استخدام Apache-Commons equalsbuilder, ، لكنه يمنحك وصفًا دقيقًا لما فشل بالضبط.

يمكنك إنشاء المطابقة المتخصصة الخاصة بك لإنشاء هذه التعبيرات بسرعة. سيكون من الحكمة نسخ Apache-Commons equalsbuilder هنا.

راجع للشغل ، Hamcrest Basic Jar هو 32 كيلو (بما في ذلك المصدر!) يمنحك خيار مراجعة الكود والقول لرؤساءك "سوف أقف إلى جانب هذا الرمز الخاص بي" (والتي أفترض أنها مشكلة الاستيراد).

Answer 2

يمكنك استخدام الجوانب لتصحيح "متساوٍ" على الفئات في الرسم البياني الكائن الخاص بك وجعلها تقوم بتسجيل حالة الكائن إلى ملف عند إرجاعها الخاطئة. لتسجيل حالة الكائن ، يمكنك استخدام شيء مثل BeanUtils لتفقد الكائن وتفريغه. هذا هو حل واحد يعتمد على الجرة ويمكن استخدامه بسهولة في مساحة العمل الخاصة بك

إذا كان التسلسل الهرمي للكائنات المخزنة في شجرتك بسيطًا بدرجة كافية ، فيمكنك وضع نقاط توقف مشروطة على فصولك "متساوية" والتي تطلق فقط عندما يعيد "متساوٍ" خطأ مما يحد من عدد المرات التي يتعين عليك فيها التدخل في ... يمكنك استخدام هذا أينما كان الوصول إلى تصحيح الأخطاء. Eclipse يتعامل مع هذا على ما يرام.

Answer 3

يبدو أنك تريد جافا ديف, أو شيء مثله.

Answer 4

حسنًا ، هذه طريقة غريبة تمامًا للنظر إليها ، ولكن ماذا عن تقديم طريقة ثابتة جديدة:

public static boolean breakableEquals(Object o1, Object o2)
{
    if (o1 == o2)
    {
        return true;
    }
    if (o1 == null || o2 == null)
    {
        return false;
    }
    // Don't condense this code!
    if (o1.equals(o2))
    {
        return true;
    }
    else
    {
        return false;
    }
}

أعلم أن الشيء الأخير يبدو غاضبًا ... لكن الفرق هو أنه يمكنك وضع نقطة توقف على "العودة الخاطئة". إذا كنت ثم استخدم breakableEquals في كل مقارنات المساواة العميقة ، يمكنك كسر بمجرد أن تضغط على الأول "return false".

هذا لا يساعد كثيرًا إذا كنت تقارن الكثير من القيم البدائية ، من المسلم به ... ولكن قد يكون مفيدًا. لا أستطيع أن أقول أنني استخدمت هذا بالفعل ، لكن لا يمكنني رؤية سبب عدم عمله. سيكون أقل كفاءة بعض الشيء ، بالطبع - لذلك إذا كنت تتعامل مع التعليمات البرمجية عالية الأداء ، فقد ترغب في تغييره بعد ذلك.

خيار آخر هو استخدام شيء مثل:

boolean result = // comparison;
return result;

على افتراض أن IDE يدعمهم ، يمكنك بعد ذلك وضع نقطة توقف مشروطة في بيان الإرجاع ، وتعيين الشرط ليكون "!result".

خيار آخر:

public static boolean noOp(boolean result)
{
    return result;
}

يمكنك بعد ذلك استخدام هذا ضمن المقارنات:

return Helpers.noOp(x.id == y.id) &&
       Helpers.noOp(x.age == y.age);

آمل أنه عندما لا تصحيح الأخطاء ، سيتم تحسين ذلك من قبل JIT - ولكن مرة أخرى ، يمكنك استخدام نقطة توقف مشروطة في noOp. إنه يجعل الكود أقصى ، للأسف.

باختصار: لا توجد حلول جذابة هنا ، ولكن فقط بعض الأفكار التي قد المساعدة في مواقف معينة.

Answer 5

لا مانع من نسخ فصل واحد ، أو حتى حزمة ، في منطقة الاختبار الخاصة بي واستخدامها هناك ، ولكن استيراد جرة كاملة لهذا لن يحدث.

أم ... ماذا؟ إن إضافة جرة إلى ClassPath ، إن وجدت ، أسهل وأقل إزعاجًا للمشروع من نسخ الفئات ، أو الحزم بأكملها كرمز مصدر.

بالنسبة لمشكلتك المحددة ، هل لديك الكثير من الفئات المختلفة التي تستخدم العديد من الخصائص المختلفة لتحديد المساواة ، أو هل لديك مجرد رسم بياني للكائن المتداخل بعمق لنفس الفئات نفسها؟ في الحالة الأخيرة ، سيكون من السهل جدًا مجرد تحريك الأساليب المتساوية () حتى تتمكن من وضع نقاط التوقف على البيانات "FALSE". في الحالة السابقة ، قد يكون هذا الكثير من العمل ، أفترض. ولكن بعد ذلك ، قد لا تعمل المقارنة المستندة إلى XML أيضًا ، لأنها ستظهر اختلافات بين الكائنات المتساوية بشكل دلالي (EG Sets والخرائط).

Answer 6

بالنظر إلى أن مشروعك لا يمكنه إضافة جرة ، يبدو أن هناك إجابة تتجاوز تمامًا لإعطاء تنفيذ كامل لحل أن المشاريع الأخرى تأخذ كمية كبيرة من التعليمات البرمجية لإنجازها (وتضمينها بشكل جيد في جرة لك).

ماذا عن الحل غير الرمز - نقاط التوقف الشرطية في مصحح الأخطاء؟ يمكنك إضافة نقاط توقف هذه الرحلة فقط إذا كانت الطريقة تُرجع كاذبة ، ووضعها على جميع الفئات ذات الصلة. لا خطوة.

Answer 7

أعلم أن إضافة الجرار هي الطريقة العادية لفعل الأشياء. أعلم أن الجرار هي وحدات قابلة لإعادة الاستخدام. ومع ذلك ، فإن البيروقراطية اللازمة (في مشروعي) لهذا لا يبرر النتائج - سأستمر في تصحيح الأخطاء والدخول.

تتمثل إحدى الطرق في هذا الأمر إلى تضمين مكتبة مثل Spring (التي تجذب الكثير من الجرة الأخرى) لقد رأيت مشروع الربيع الذي لم يستخدم فعليًا أي جرة الربيع حتى يتمكنوا من استخدام أي جرة مجمعة معها.

Answer 8

المشاعات-JXPath قد يكون من المفيد فحص شجرة الكائن بسرعة. لا أفهم تمامًا مشكلة تضمين الجرار ، ولكن يمكنك فقط استخدامها في مشروعك الخاص في أي IDE التي تستخدمها والتي من المفترض أن تستخدم التعبيرات أثناء تصحيح الأخطاء.

Answer 9

ربما هذا مقالة - سلعة حول تتبع الطريقة سوف يساعدك.

كيف تعمل

يقرأ محمل الفئة المخصصة ملف الفئة والأدوات لكل طريقة باستخدام رمز التتبع. يضيف Loader الفئة أيضًا حقلًا ثابتًا إلى كل فئة. هذا المجال له دولتين ، "على" و "OFF". يتحقق رمز التتبع في هذا الحقل قبل الطباعة. خيارات سطر الأوامر وصول وتعديل هذا الحقل الثابت للتحكم في إخراج التتبع.

يبدو أن عينة الإخراج التي تظهرها واعدة لمشكلتك ، حيث إنها توضح قيمة إرجاع بعض الطرق (مثل Isapplet):

isApplet = false

يجب أن يكون من السهل عليك اكتشاف الفئة الدقيقة التي بدأت في العودة كاذبة إلى حد ما. إليك عينة كاملة من الصفحة:

٪ java -jar /home/mike/java/trace.jar -classpath "/home/mike/jdk1.3/demo/jfc/swingset2/swingset2
| Swingset2. ()
| Swingset2.
| Swingset2.main ([ljava.lang.string ؛@1dd95c)
|| isapplet (Swingset2@3d12a6)
|| isapplet = false
|| Swingset2.CreateFrame (Apple.Awt.CgraphicsConfig@93537d)
||swingset2.createframe=javax.swing.jframe@cb01e3
|| createSplashScreen (Swingset2@3d12a6)
||| createImageIcon (Swingset2@3d12a6 ، "splash.jpg" ، "splash.accessible_description")
||| createimageicon=javax.swing.imageicon@393e97
||| isApplet (Swingset2@3d12a6)
||| isapplet = false
||| getFrame (Swingset2@3d12a6)
||| GetTframe=Javax.swing.jframe@cb01e3
||| getFrame (Swingset2@3d12a6)
||| GetTframe=Javax.swing.jframe@cb01e3
|| CreateSplashScreen
.Run (Swingset2 $ 1@FBA2AF)
..showsplashscreen (Swingset2@3d12a6)
... isApplet (Swingset2@3d12a6)
... isApplet = false
..showsplashscreen
.يجري
|| initializeemo (swinget2@3d12a6)
||| createMenus (Swingset2@3d12a6)
|||| getString (Swingset2@3d12a6 ، "menubar.accessible_description")
||||| getResourceBundle (Swingset2@3d12a6)
عند
||| و getString = "شريط قائمة الأرجوحة التجريبية"

Answer 10

يقوم Xmlencoder بتشفير خصائص الفاصوليا فقط ، في حين أن المساواة يمكن ، من الواضح ، العمل على غير الفوّل وأي حقول داخلية.

جزء من المشكلة هو أنك لا تعرف ما يساوي النظر بالفعل. يمكن أن يكون للكائن العديد من الحقول المختلفة ولا يزال يزعم أنه كان مساوياً لبعض الكائنات الأخرى ، فقد يكون نوعًا مختلفًا. (على سبيل المثال ، قد تعود فئة URL المخصصة إلى سلسلة تساوي شكلها الخارجي).

لذلك لا أعتقد أنه من الممكن بدون أجهزة Bytecode حيث يمكنك فعليًا تعديل الدالة المساواة في الفئات () لمعرفة الحقول التي تصل إليها. حتى ذلك الحين ، سيكون من الصعب للغاية "معرفة" سبب عودة وظيفة كاذبة. لكن نأمل أن تكون مشكلة بسيطة في مقارنة الحقول التي يتم الوصول إليها بالفعل في متساوٍ ()