الاستثناءات والجراجات

Question

متى يجب أن ترمي استثناء مخصص؟

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

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

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

Answer 1

أود أن أتحدث استثناءات من حيث ما طلبته من الطريقة الأصلية للقيام به. على سبيل المثال

read -> ReadException
connect -> ConnectException
buildPortfolio -> FailedToBuildPortfolioException

إلخ. هذه الملخصات بعيدا ما يحدث تحت الأغطية (أي أنت تقترب عبر مآخذ وما إلى ذلك). كقاعدة عامة، عندما أقوم بإنشاء واجهة لعنصر، غالبا ما أنشئ استثناء أو مجموعة من الاستثناءات المقابلة. وسيتم استدعاء واجهة بلدي Component, ، واستثناءاتي عادة ComponentException (على سبيل المثال RateSource و RateSourceException). انها متسقة وسهلة التصدير إلى مشاريع مختلفة كمجموعة مكون كاملة.

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

في مرحلة ما أثناء تسلسل التسلسل الهرمي للمكالمات (وبالتالي الاستثناءات) قد تقرر أنه لا يمكن أن يحدث أي استرداد (أو أنه بمكان غير مناسب) وترجم إلى استثناءات غير محددة يتم التعامل معها لاحقا.

Answer 2

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

لذلك، للحصول على رمز C ++ الخاص بي - نوع واحد من الاستثناء، يحتوي على رسالة خطأ ذات مغزى، لكل مكتبة. وواحد للتنفيذ النهائي.

Answer 3

أعتقد أن هناك سؤالان مخبأان هنا: أ) متى يجب أن يخفي المرء استثناء خلف استثناء مختلف. ب) متى يجب على المرء استخدام استثناء مخصص لهذا.

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

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

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

ج) على الأقل في جافا هناك مناقشة حول استثناءات فحصها. أنا التفاف تلك مباشرة في واحد غير مروع، لأنني أكره نوع فحصه. ولكن هذا هو أكثر رأي ثم المشورة.

Answer 4

هل هناك أي حالة حيث يمكنك الحصول على noconnectionException والتي لا تسببها مشكلة IO؟ على العكس، هل يعرف ما إذا كان السبب يعتمد على IO أو لن يساعد العميل على استعادة المعقول؟

Answer 5

متى يجب أن ترمي استثناء مخصص؟

1. عندما يمكنك تقديم معلومات أكثر (تشخيصية).

ملاحظة: قد لا تكون هذه المعلومات الإضافية متاحة في المكان الذي تم طرح فيه الاستثناء الأصلي (IoException). قد تحتوي طبقات التجراجية التقدمية على مزيد من المعلومات لإضافة مثل ما كنت تحاول القيام به الذي أدى إلى هذا الاستثناء؟

II. عندما لا يجب عليك عرض تفاصيل التنفيذ: أي تريد التجريد (وهم؟) للمتابعة.

قد يكون هذا مهما عندما يمكن أن تتغير آلية التنفيذ الأساسية. التفاف الاستثناء الكامن وراء الاستثناء المخصص هو وسيلة جيدة لعزل عملائك من تفاصيل التنفيذ (من خلال رفع مستوى التجريد)

III. كل من أنا والثاني

ملاحظة: علاوة على ذلك، يجب أن يكون عملائك قادرين على ضبط المستوى الدقيق للمعلومات التي يهتمون بها أو بالأحرى يجب أن تكون قادرة على ضبط أي شيء غير مهتم بهم. لذلك من الجيد أن تستمد استثناءاتك المخصصة من IoException.