هل من الممكن استرداد مكدس الاستدعاءات برمجياً في VB6؟

Question

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

Answer 1

أنا متأكد من أن عليك القيام بذلك بالطريقة الصعبة.في وظيفة سابقة لي، كان لدينا عملية معالجة أخطاء أنيقة للغاية لـ VB6 مع مكونات DCOM.ومع ذلك، كان هناك الكثير من التعليمات البرمجية الزائدة عن الحاجة والتي كان لا بد من إضافتها إلى كل طريقة، لدرجة أنه كان لدينا أدوات محلية لإدراجها كلها نيابة عنك.

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

هث

Answer 2

عليك أن تفعل ذلك بالطريقة الصعبة، ولكن هذا ليس كل شيء حقًا الذي - التي صعب...على محمل الجد، بمجرد كتابة القالب مرة واحدة، يتم إجراء نسخ/لصق/تعديل سريع لمطابقة اسم الوظيفة في بيان Err.Raise مع اسم الوظيفة الفعلي.

Private Function DoSomething(ByVal Arg as String)

    On Error GoTo Handler

    Dim ThisVar as String
    Dim ThatVar as Long

    ' Code here to implement DoSomething...

    Exit Function

Handler:
    Err.Raise Err.Number, , "MiscFunctions.DoSomething: " & Err.Description

End Function

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

لاحظ أيضًا أنه داخل الوظيفة نفسها، يمكنك إثارة الأخطاء الخاصة بك باستخدام قيم المتغيرات المثيرة للاهتمام في الرسالة كما يلي:

Err.Raise PCLOADLETTER_ERRNUM, , "PC Load Letter error on Printer """ & PrinterName & """"

(يبدو تمييز بناء الجملة متزعزعًا في المعاينة...أتساءل كيف سيبدو عند النشر؟)

Answer 3

الطريقة الصعبة واليدوية هي الطريقة الوحيدة تقريبًا.إذا قمت بالخروج هذا سؤال، اقترح شخص ما أداة تسمى MZTools من شأنها أن تقوم بالكثير من العمل الشاق نيابةً عنك.

Answer 4

وكما قال الآخرون (منذ سنوات، أرى...ولكن لا يزال هناك الكثير من الأشخاص الذين يستخدمون VB6!:) )، أعتقد أنه من غير الممكن استرداد Call Stack برمجيًا، إلا إذا كنت تستخدم بعض أدوات الطرف الثالث.

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

Sub MyRoutine
    (...)  ' Your code here
    call DoSomething (Var1, Var2, Var3, "MyRoutine")
    '                                       ^
    '     Present routine's name -----------+

    (...)  ' Your code here

End Sub


Public DoSomething (DoVar1, DoVar2, DoVar3, Optional Caller as string = "[unknown]")
    Debug.Print " DoSomething Routine Called. Caller = " & Caller

    ... ' (your code here)

End Sub

ربما لم تكن أنيقة جدًا، لكنها نجحت بالنسبة لي.

التحيات ، ماكس - إيطاليا

Answer 5

Compuware (أو كان Numega في ذلك الوقت) يستخدم DevStudio لـ Visual Basic 6 للقيام بذلك.كانت الطريقة هي إضافة أدوات إلى كل مكالمة تسمى مقتطفًا صغيرًا جدًا يُضاف إلى حزمة التعليمات البرمجية.عند حدوث أي خطأ، يتم التخلص من مكدس الاستدعاءات هذا، ثم القيام بأشياء مثل البريد أو النشر على خادم الويب لجميع معلومات تصحيح الأخطاء.كانت إضافة الأجهزة وإزالتها عملية قاتلة (خاصة في ذلك الوقت، عندما كنا نستخدم VSS كعنصر تحكم في المصدر)، ولكن إذا نجحت، فإنها تعمل بشكل جيد.

مثل وأشار داريل, يمكنك إضافة شيء مشابه جدًا باستخدام MZTools وإعداد قالب.إنه يتطلب الكثير من العمل، وربما يكون مجهودًا أكبر من المكافأة، ولكن إذا كان من الصعب جدًا تعقب الأخطاء، فقد يكون ذلك مفيدًا).