العودة المنطقية بدلاً من إعلان نوع فراغ في جافا؟

Question

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

Answer 1

عادة ما أستخدمه ExceptionS للإشارة عندما حدث خطأ ما.

بدلا من العودة false, ، تستطيع throw و Exception مع رسالة مفصلة حول المشكلة.

عودة false لا يعطيك الكثير من المعلومات حول المشكلة.

ثم ، بدلاً من التحقق من أ false قيمة الإرجاع ، فقط ضع استدعاء الطريقة في try/catch إذا كنت تتوقع أن تفشل الطريقة بسهولة.

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

Answer 2

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

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

Answer 3

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

لجميع الأشياء الأخرى حيث أنت فكر في يمكنك تقديمه ، ربما يعني أنك تتعامل مع نوع من Exception, ، وأنت حقًا لا تريد أن تغلف ذلك مع منطقية بسيطة true/false, ، لأنه يمكن أن يكون لديك مجموعة متنوعة من النكهات (استثناءات مختلفة) وأسباب حدوث خطأ ما ، والذي تريد معرفته.

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

Answer 4

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

Answer 5

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

يحدث هذا النمط في مكتبات Java الأساسية. نرى file.delete () كمثال.

Answer 6

لعودة النجاح بشكل عام ما تراه هو:

• العودة المنطقية
• إرجاع الفراغ ، ولكن رمي الاستثناء على الخطأ
• إرجاع رمز الحالة (أقل شيوعًا في Java).

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

Answer 7

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

Answer 8

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

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

حقا هذا هو معنيان مختلفتان تمامًا لكلمة "خطأ" ، وهم يدعون إلى التعامل مختلف. من الممكن تمامًا أن تفعل نفس الوظيفة. مثل ، في العثور على Return True ، في عدم العثور على عودة خطأ ، على خطأ I/O في محاولة لقراءة استثناء.

Answer 9

يبدو الأمر جيدًا ، لكن الشيطان يكمن في التفاصيل. ؛-)

إلقاء استثناء هو البديل الرئيسي ، مع إيجابيات وسلبيات.

أعتقد أنه يمكنك الحصول على مزيد من البصيرة من خلال توفير عينات ترميز دقيقة ...