الاستثناءات مقابل رموز النتائج لفئة عميل مأخذ التوصيل

Question

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

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

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

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

شكرًا.

Answer 1

أعتقد أن استراتيجيتك سليمة في الأساس.

ضع في اعتبارك أن الغرض من الاستثناءات هو التعامل مع الظروف الاستثنائية.كلما اقتربت من مصدر المشكلة كلما كان ذلك أفضل.

في حالتك، يبدو أن استراتيجيتك هي شيء من هذا القبيل "لم تنجح الآن.دعونا نعيد المحاولة".لا أرى سببًا لإثارة الاستثناءات حقًا.

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

فلسفتي بشأن الاستثناءات هي أنها يجب أن تكون لظروف استثنائية لا يمكنك التعامل معها حقًا.مقبس مغلق؟امممم...كم مرة ينقطع الانترنت في منزلي...

Answer 2

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

عند الاتصال بـ yourObject.BeginAsyncUploadFile()، أتوقع نفس السلوك باستثناء أنني سأحتاج إلى الانتظار على IAsyncResult أو كائن مكافئ لمعرفة ما إذا كان تحميل الملف قد نجح أم لا ثم التحقق من خاصية الاستثناء/الخطأ إذا كان لم يفعل ذلك.

Answer 3

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

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

Answer 4

هذا سؤال مثير للاهتمام إلى حد ما.على هذا النحو، ربما لا توجد إجابة "صحيحة بنسبة 100%"، ويعتمد ذلك في الغالب على كيفية تنظيم التعليمات البرمجية التي تستخدم وظيفتك في رأيك.

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

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

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

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