الشروط المسبقة والاستثناءات

Question

لنفترض أن لديك طريقة مع بعض الشروط المسبقة واللاحقة.هل من المقبول إنشاء فئة استثناء لكل شرط مسبق لم يتم تحقيقه؟على سبيل المثال:عدم إنجاز pre1 يعني طرح مثيل notPre1Exception.

Answer 1

نعم و لا.

نعم - إن انتهاك شرط مسبق هو بالتأكيد الوقت المناسب لطرح استثناء.سيؤدي طرح استثناء أكثر تحديدًا إلى تسهيل اكتشاف هذا الاستثناء المحدد.

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

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

Answer 2

لماذا لا تريد تحديد PreconditionFailedException(سلسلة شرط مسبق)؟يعد طرح نوع استثناء مختلف لكل شرط مسبق فاشل أمرًا مبالغًا فيه.

Answer 3

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

Answer 4

فقط في حالة عدم تحقيق الشروط المسبقة سيكون أمرًا نادرًا استثنائي حادثة.

Answer 5

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

Answer 6

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

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

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

Answer 7

يبدو الأمر ممكنًا بالنسبة لي، ولكن إذا كنت تريد الاستمرار بهذه الطريقة في التعامل مع الشروط المسبقة، فسينتهي بك الأمر بفئات استثناء N لكل طريقة فئة.يبدو وكأنه نمو هائل للفئات "غير الوظيفية".

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

Answer 8

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

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

أدرك أن الاستثناءات لا تتبع هذه القاعدة دائمًا، لكنني أعتقد أن هذا يرجع إلى حد ما إلى أن الاستثناءات التي توفرها اللغة لا يمكن أن تحتوي على أي منطق عمل (لأنهم لا يعرفون الأعمال - تميل المكتبات دائمًا إلى أن تكون مليئة بالاستثناءات لقواعد OO)

Answer 9

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

Answer 10

لا، لا ينبغي عليك إنشاء استثناء محدد لكل شرط مسبق لأنه سيتعارض مع مبادئ التصميم حسب العقد.

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

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

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

Answer 11

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

Answer 12

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