لماذا نتحدث عن معالجة الاستثناء في مشروع J2EE؟ ربما يريد العديد من المبتدئين في Java أن يقولوا ، "أليس الاستثناء معالجة فقط حاول .... تمسك ... أخيرًا؟ الجميع يعرف هذا!" يفكر المؤلف أيضًا بهذه الطريقة عندما يكون مبتدئًا في جافا. كيفية تحديد فئة الاستثناء المقابلة في مشروع J2EE متعدد الطبقات؟ كيفية التعامل مع الاستثناءات في كل طبقة في المشروع؟ متى يتم طرح الاستثناء؟ متى يتم تسجيل الاستثناء؟ كيف تسجل استثناءات؟ متى يجب أن أحول الاستثناء الذي تم فحصه إلى استثناء غير محدد ، ومتى يجب أن أقوم بتحويل استثناء لم يتم التحقق منه إلى استثناء محدد؟ هل يجب تقديم الاستثناء إلى الصفحة الأمامية؟ كيفية تصميم إطار استثناء؟ ستتم مناقشة هذه القضايا في هذه المقالة.
1. جافا استثناء معالجة
في لغات البرمجة الإجرائية ، يمكننا تحديد ما إذا كان يتم تنفيذ الطريقة بشكل طبيعي عن طريق إعادة القيمة. على سبيل المثال ، في برنامج مكتوب بلغة C ، إذا تم تنفيذ الطريقة بشكل صحيح ، فسيتم إرجاع 1. إذا تم تنفيذ الخطأ ، فسيتم إرجاع 0.
لا يمكننا الحصول على تفاصيل الخطأ من خلال قيمة إرجاع الطريقة. قد يكون ذلك لأن الطريقة مكتوبة من قبل مبرمجين مختلفين ، عندما يحدث نفس النوع من الخطأ بطرق مختلفة ، فإن النتائج المعتمدة ومعلومات الخطأ غير متسقة.
لذلك ، تعتمد لغة جافا آلية معالجة استثناء موحدة.
ما هو الاستثناء؟ أخطاء قابلة للقبض وقابلة للتصحيح تحدث في وقت التشغيل.
في لغة جافا ، الاستثناء هو الفئة الوالدية لجميع الاستثناءات. يتم تمديد أي استثناء إلى فئة الاستثناء. الاستثناء يعادل نوع الخطأ. إذا كنت ترغب في تحديد نوع خطأ جديد ، فقم بتمديد الفئة الفرعية الاستثناء الجديد. تتمثل ميزة استخدام الاستثناءات في أنه يمكن تحديد موقع موقع الكود المصدر بدقة التي تسبب خطأ البرنامج والحصول على معلومات خطأ مفصلة.
يتم تطبيق معالجة استثناء Java من خلال خمس كلمات رئيسية ، حاول ، الصيد ، رمي ، رميات ، أخيرًا. يتم تنفيذ بنية معالجة الاستثناء المحددة من خلال المحاولة ... Try Block Stores Java التي قد يكون لها استثناءات. يتم استخدام الصيد لالتقاط استثناءات والتعامل مع الاستثناءات. يتم استخدام الكتلة النهائية لمسح الموارد غير المجانية في البرنامج. يتم تنفيذ الكتلة النهائية دائمًا إذا كانت الرمز الذي لا يدير كيفية إرجاع كتلة المحاولة.
رمز معالجة استثناء نموذجي
السلسلة العامة getPassword (سلسلة userId) يلقي DataAccessException {String sql = "حدد كلمة المرور من userInfo حيث userId = '" +userId +"' '' بينما (rs.next ()) {password = rs.getString (1) ؛} rs.close () ؛ s.close () ؛} catch (sqlexception ex) {رمي البيانات الجديدة (ex) ؛ فشل! "، sqlex) ؛}} إرجاع كلمة المرور ؛} يمكن ملاحظة أن مزايا آلية معالجة استثناءات جافا:
يتم تصنيف الخطأ بشكل موحد وتطبيقه من خلال توسيع فئة الاستثناء أو فئة الفئة الفرعية. هذا يتجنب أن الخطأ نفسه قد يكون له رسائل خطأ مختلفة في طرق مختلفة. عندما يحدث الخطأ نفسه في طرق مختلفة ، تحتاج فقط إلى رمي نفس كائن الاستثناء.
الحصول على مزيد من معلومات الخطأ التفصيلية. من خلال فئات الاستثناء ، يمكن تقديم معلومات الخطأ إلى الاستثناء الذي يكون أكثر تفصيلاً وأكثر فائدة للمستخدم. من السهل على المستخدمين تتبع برامج وتصحيح الأخطاء.
افصل نتيجة الإرجاع الصحيحة عن رسالة الخطأ. يقلل من تعقيد البرنامج. لا يحتاج المتصل إلى معرفة المزيد عن نتيجة العودة.
إجبار المتصل على التعامل مع الاستثناءات لتحسين جودة البرنامج. عندما يحتاج إعلان الطريقة إلى إلقاء استثناء ، يجب على المتصل استخدام المحاولة .... Catch Block للتعامل مع الاستثناء. بالطبع ، يمكن للمتصل أيضًا السماح للاستثناء بالاستمرار في إلقاءه على المستوى العلوي.
2. استثناء فحص أو استثناء غير محدد؟
تنقسم استثناءات Java إلى فئتين: استثناء تم فحصه واستثناء غير محدد. جميع الاستثناءات التي ترث java.lang.exception تنتمي إلى استثناءات محددة. جميع الاستثناءات التي ترث java.lang.runtimeexception تنتمي إلى استثناءات غير محددة.
عندما تستدعي طريقة ما طريقة قد ترمي استثناءًا محددًا ، يجب التقاط الاستثناء ومعالجته أو إعادة صياغته خلال المحاولة ... Catch Block.
دعنا نلقي نظرة على إعلان طريقة CreateStatement () لواجهة الاتصال.
البيان العام الإبداعي () يلقي sqlexception ؛ Sqlexception هو استثناء محدد. عندما تسمى طريقة الإبداع ، يفرض جافا المتصل على التقاط sqlexception. السلسلة العامة getPassword (String userId) {try {... repate s = con.createstatement () ؛ ... catch (sqlexception sqlex) {...} ...} أو
السلسلة العامة getPassword (String userId) يلقي sqlexception {statle s = con.createstatement () ؛} (بالطبع ، يجب إغلاق الموارد مثل الاتصال وال سبح في الوقت المناسب. هذا فقط لتوضيح أن الاستثناء الذي تم فحصه يجب أن يجبر المتصل على التقاط أو الاستمرار في رمي)
يسمى الاستثناء غير المحدد أيضًا استثناء وقت التشغيل. عادةً ما يشير RunTimeException إلى استثناء أنه لا يمكن للمستخدم استرداد ، مثل عدم القدرة على الحصول على اتصال قاعدة بيانات ، وعدم القدرة على فتح ملف ، وما إلى ذلك. ولكن إذا لم يلتزم المتصل بالاستثناء الذي لم يتم التحقق منه ، فلن يجبرك المترجم على القيام بذلك.
على سبيل المثال ، رمز يحول الأحرف إلى قيم عدد صحيح كما يلي:
سلسلة str = "123" ؛ int value = integer.parseint (str) ؛
توقيع طريقة Parseint هو:
parseint staticint العامة (سلسلة S) يلقي numberformatexception
عندما لا يمكن تحويل المعلمات التي تم تمريرها إلى عدد صحيح مقابل ، سيتم إلقاء رقم formformatexception. نظرًا لأن NumberFormatexception يمتد إلى RunTimeException ، فهو استثناء غير محدد. لذلك ليست هناك حاجة لمحاولة ... التقاط عند الاتصال بطريقة الحاجز
لأن Java لا يجبر المتصل على التقاط أو رمي الاستثناء غير المرغوب فيه. لذلك يحب المبرمجون دائمًا رمي استثناءات غير محددة. أو عندما تكون هناك حاجة إلى فئة استثناء جديدة ، يتم استخدامها دائمًا للتمديد من RunTimeException. عندما تتصل بهذه الأساليب ، إذا لم يكن هناك كتلة مقابلة مقابلة ، فسوف يسمح لك المترجم دائمًا بالمرور ، ولا تحتاج إلى فهم ما الذي ستعرضه هذه الطريقة. يبدو أن هذه فكرة جيدة ، لكن القيام بذلك بعيدًا عن النية الحقيقية للتعامل مع استثناء جافا. وهو مضلل للمبرمج الذي يدعو إلى صفك ، لأن المتصل ليس لديه أي فكرة في ظل الظروف التي يحتاجها للتعامل مع الاستثناءات. يمكن أن يخبر الاستثناء الذي تم فحصه بوضوح المتصل عن الاستثناءات التي يجب معالجتها عند استدعاء هذه الفئة. إذا لم يعالج المتصل ذلك ، فسيتم المطالبة بالمترجم ولا يمكنه تجميعه ويمر. بالطبع ، كيف تتعامل مع الأمر متروك للمتصل لاتخاذ قرار.
لذا توصي Java أن يستخدم الأشخاص استثناءات محددة في رمز التطبيق الخاص بهم. كما ذكرنا في القسم السابق أن ميزة استخدام الاستثناءات هي أنه يمكن أن يجبر المتصل على التعامل مع الاستثناءات التي سيتم إنشاؤها. يتم استخدام الاستثناءات التي تم فحصها كمعيار في مستندات Java الرسمية مثل "Java Tutorial".
يجب أن يعني استخدام الاستثناءات المحددة أن هناك الكثير من المحاولة ... المصيد في الكود الخاص بك. بعد الكتابة والتعامل مع المزيد والمزيد من المحاولة ... تم التقاط الكتل ، بدأ العديد من الأشخاص أخيرًا في التساؤل عما إذا كان ينبغي استخدام الاستثناءات التي تم فحصها كمعيار.
حتى بروس إيكل ، مؤلف كتاب "التفكير في جافا" الشهير ، غير أفكاره السابقة. يدعو بروس إيكل حتى استخدام استثناءات غير محددة كاستخدام قياسي. ونشر مقالًا لاختبار ما إذا كان ينبغي إزالة الاستثناء الذي تم فحصه من Java. Bruce Eckel: "عندما تكون كمية صغيرة من التعليمات البرمجية ، تكون الاستثناءات التي تم فحصها بلا شك مفهومًا أنيقًا للغاية وتساعد على تجنب العديد من الأخطاء المحتملة. لكن التجربة تُظهر أن النتيجة هي عكس ذلك تمامًا لكمية كبيرة من التعليمات البرمجية."
للحصول على مناقشات مفصلة حول الاستثناءات التي تم فحصها واستثناءات غير مرتاح ، يرجى الرجوع إلى
Java Tutorial http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html
يمكن أن يسبب استخدام الاستثناءات المحددة العديد من المشكلات.
الاستثناء الذي تم فحصه يسبب الكثير من المحاولة ... Catch Code
قد يكون هناك العديد من الاستثناءات التي تم فحصها والتي لا يمكن معالجتها بشكل معقول من قبل المطورين ، مثل SQLexception. لكن على المطورين أن يحاولوا ... الصيد. عندما لا يتمكن المطورون من التعامل مع استثناء تم فحصه بشكل صحيح ، فإنهم عادة ما يطبعون الاستثناء أو لا يفعلون شيئًا. خاصة بالنسبة للمبتدئين ، فإن الكثير من الاستثناءات التي تم فحصها تجعله يشعر بالخسارة.
حاول {... بيان s = con.createstatement () ؛ ... catch (sqlexception sqlex) {sqlex.printstacktrace () ؛} أو
جرب {... بيان s = con.createstatement () ؛ ... catch (sqlexception sqlex) {// لا شيء} يؤدي الاستثناء الذي تم فحصه
عندما يتعين على المطورين التقاط استثناء تم فحصه بأنهم لا يستطيعون التعامل بشكل صحيح ، يتم إعادة تعبئة عادة في استثناء جديد ثم يتم إلقاؤهم. القيام بذلك لا يجلب أي فوائد للبرنامج. بدلاً من ذلك ، يجعل من الصعب فهم الكود لاحقًا.
تمامًا مثلما نستخدم رمز JDBC ، هناك الكثير من المحاولة ... يتم تضمين الكود المفيد حقًا في المحاولة ... الصيد. مما يجعل من الصعب فهم هذه الطريقة
يتسبب الاستثناء الذي تم فحصه في أن يتم تغليف الاستثناء باستمرار في استثناء فئة أخرى ثم يتم إلقاؤه
methoda public void methoda () يلقي استثناء {… .. response new stistenta () ؛} public void methodb () يلقي استثناء {try {methoda () ؛ ...} catch (استثناء ex) {thow stistentionB (ex) ؛}} نرى أن الاستثناء مغلف وطبقة من قبل الطبقة.
الاستثناء الذي تم فحصه يسبب فساد طريقة الواجهة
تم استخدام طريقة على واجهة من قبل فئات متعددة. عند إضافة استثناء إضافي تم فحصه إلى هذه الطريقة ، يجب تعديل جميع الرموز التي تستدعي هذه الطريقة.
يمكن أن نرى أن المشكلات المذكورة أعلاه تُجبر على التقاط المعالجة لأن المتصل لا يمكنه التعامل مع الاستثناء الذي تم فحصه بشكل صحيح ، ويتم إجبارهم على التغليف ثم إعادة التهوية. هذا غير مريح للغاية ولا يجلب أي فوائد. في هذه الحالة ، عادة ما تستخدم الاستثناءات غير المحددة.
الاستثناء المحدد ليس كل شيء. الاستثناء الذي تم التحقق منه أسهل بكثير من قيمة إرجاع الخطأ للبرمجة التقليدية. من الأفضل بكثير التأكد من معالجة الاستثناءات بشكل صحيح من خلال المترجم بدلاً من الحكم على قيمة الإرجاع.
إذا كان استثناء قاتلاً ، فهذا أمر غير قابل للاسترداد. أو يذهب المتصل للقبض عليه دون أي فائدة ، استخدم الاستثناء غير المحدد.
إذا كان يمكن استرداد استثناء ويمكن معالجته بشكل صحيح من قبل المتصل ، فاستخدم الاستثناء الذي تم فحصه.
عند استخدام استثناء غير محدد ، يجب وصف الاستثناء غير المتواصل بأنه قد يتم وصف الطريقة بالتفصيل في إعلان الطريقة. يقرر المتصل ما إذا كان سيتم التقاط الاستثناء الذي لم يتم التحقق منه
متى تستخدم استثناءات محددة ، ومتى تستخدم استثناءات غير محددة؟ لا يوجد معيار مطلق. لكن يمكنني تقديم بعض الاقتراحات
عندما يتعين على جميع المتصلين التعامل مع هذا الاستثناء ، يمكن السماح للمتصل بإعادة تشغيل العملية ؛ أو الاستثناء يعادل قيمة الإرجاع الثانية للطريقة. استخدم استثناء محدد.
لا يمكن معالجة هذا الاستثناء إلا من قبل عدد قليل من المتصلين المتقدمين ، ولا يمكن للمتصلين العاديين التعامل معه بشكل صحيح. استخدم استثناء غير محدد. يمكن للمتصلين الذين لديهم القدرة على المعالجة أداء معالجة متقدمة ، ولكن بشكل عام لا يتعامل المتصلين على الإطلاق.
هذا الاستثناء هو خطأ خطير للغاية ، مثل أخطاء اتصال قاعدة البيانات ، وفشل الملف في فتح ، وما إلى ذلك أو هذه الاستثناءات مرتبطة بالبيئة الخارجية. لا يمكن حل مشكلة إعادة المحاولة. استخدم استثناء غير محدد. لأنه بمجرد حدوث هذا الاستثناء ، لا يمكن للمتصل التعامل معه على الإطلاق.
إذا لم يكن الأمر متأكدًا ، فاستخدم استثناء غير محدد. وصف بالتفصيل الاستثناء الذي قد يتم إلقاؤه للسماح للمتصل بتقرير ما إذا كان سيتم التعامل معه.
3. تصميم فئة استثناء جديدة
عند تصميم فئة استثناء جديدة ، تحقق أولاً مما إذا كانت فئة الاستثناء هذه مطلوبة حقًا. بشكل عام ، حاول عدم تصميم فصول استثناء جديدة ، ولكن حاول استخدام فصول الاستثناء الموجودة بالفعل في Java.
يحب
غير unalfalArgumentException ، غير مدعوم
سواء كان ذلك هو الاستثناء الجديد ، أو استثناء chekced أو استثناء غير محدد. علينا جميعًا أن ننظر في مشكلة التعشيش في الاستثناءات.
Methoda public void () يلقي استثناء {... .. استثناء جديد () ؛} طريقة إعلان الطريقة يلقي استثناء.
طريقة الفراغ العام () يلقي استثناء ب
سوف إعلان MethodB رمي الاستثناء. عندما يتم استدعاء Methoda في طريقة MethodB ، لا يمكن معالجة الاستثناء ، لذلك يجب أن تستمر الاستثناء في التغلب. طريقة واحدة هي جعل إعلان MethodB رمي استثناء. ولكن هذا قد غير توقيع طريقة الطريقة. بمجرد التغيير ، يجب تغيير جميع الطرق التي طريقة الاتصال.
هناك طريقة أخرى تتمثل في تغليف الاستثناء إلى استثناء ثم رميها. إذا لم نقم بتغليف الاستثناء في استثناء ، فسنفقد معلومات استثناء الجذر ، مما يجعل من المستحيل تتبع المصدر الأصلي للاستثناء.
method public void methodb () rems {try {methoda () ؛ ...} catch (استثناء ex) {رمي استثناء جديد (ex) ؛}} كما في الكود أعلاه ، يستثني الاستثناء استثناء. سوف نسمي الاستثناء "استثناء" في الوقت الحالي ، لأن الاستثناء يتسبب في حدوث استثناء. هذا سيمنع المعلومات الاستثناء من فقدانها.
لذلك عندما نحدد فئة استثناء جديدة ، يجب أن نقدم هذا المُنشئ الذي يمكن أن يحتوي على استثناءات متداخلة. وهناك عضو خاص لتوفير هذا "استثناء السبب".
استثناء الفئة العامة يمتد الاستثناء {private throwable cause ؛ public stisplyb (سلسلة msg ، رمي Ex) {super (msg) ؛ this.cause = ex ؛} استثناء عام (سلسلة msg) {super (msg) ؛} استثناء عام (رمي ex) {this.cause = ex ؛}} بالطبع ، عندما نسمي طريقة printstacktrace ، نحتاج إلى طباعة جميع معلومات "استثناء" في نفس الوقت. لذلك نحن بحاجة إلى تجاوز طريقة PrintStackTrace لعرض جميع آثار مكدس الاستثناء. يتضمن آثار مكدس الاستثناءات المتداخلة.
Public void printstacktrace (printstrean ps) {if (cause == null) {super.printStackTrace (ps) ؛} آخر {ps.println (this) ؛ cause.printstacktrace (ps) ؛}} الدعم الكامل لرمز مصدر فئة الاستثناء المتداخل هو كما يلي. دعنا نسميها Nestcepception هنا في الوقت الحالي
يمتد Nestceception العام الاستثناء {سبب رمي خاص ؛ Public Nestception (String msg) {super (msg) ؛} public nestection (String msg ، reflable ex) {super (msg) ؛ this.cause = ex ؛} public thrains getCause () {return (this.cause == null؟ super.getMessage () ؛ cause قابلة للتسمية = getCause () ؛ if (cause! = null) {message = message + "؛ استثناء متداخل هو" + سبب ؛ NULL) {super.printstacktrace (ps) ؛} آخر {ps.println (this) ؛ getCause (). null) {super.printstacktrace (pw) ؛} else {pw.println (this) ؛ getCause ().أيضًا ، تحتاج إلى تصميم فئة استثناء غير محددة على النحو الوارد أعلاه. إنها تحتاج فقط إلى وراثة RunTimeException.
4. كيفية تسجيل الاستثناءات
كنظام تطبيق كبير ، يلزم تسجيل ملفات السجل لتسجيل تشغيل النظام لتسهيل تتبع وتسجيل تشغيل النظام. من الطبيعي أن يتم تسجيل الاستثناءات التي تحدث في النظام في نظام السجل.
السلسلة العامة getPassword (سلسلة userId) يلقي nosuchuserexception {userInfo user = userDao.queryUserById (user user) ؛ if (user == null) {logger.info ("لا يمكن العثور على معلومات المستخدم ، userId ="+userId) ؛ رمي nosuchuseceception جديد ( user.getPassword () ؛}} public void sendUserPassword (سلسلة userId) يلقي استثناء {userInfo user = null ؛ try {user = getPassword (userId) ؛ // ..... لاحظنا أنه تم تسجيل خطأ مرتين. في أصل الخطأ ، نسجل فقط على مستوى المعلومات. في طريقة SendUserPassword ، نقوم أيضًا بتسجيل معلومات الاستثناء بأكملها.
شهد المؤلف العديد من المشاريع سجلات سجلات بهذه الطريقة ، بغض النظر عن 3721 ، وسيتم تسجيل الاستثناء بأكمله فقط عند مواجهة استثناء. إذا تم تغليف استثناء بشكل مستمر وإلقاءه عدة مرات ، فسيتم تسجيله عدة مرات. إذن أين يجب تسجيل الاستثناء؟
يجب تسجيل الاستثناء في الموقع الأولي!
إذا كان عليك التقاط استثناء لا يمكن معالجته بشكل صحيح ، فما عليك سوى تغليفه في استثناء آخر ورميه. ليست هناك حاجة لتسجيل الاستثناء المسجل مرة أخرى.
إذا تم اكتشاف استثناء ، يمكن معالجة هذا الاستثناء. لا يلزم تسجيل استثناءات
Date Date getDate (String str) {date applicdate = null ؛ simpledateformat format = new SimplEdateFormat ("mm/dd/yyyy") ؛ try {applicdate = format.parse (applateddate) ؛} catch (parseException ex) {why ، when the format ens} return. عندما يتم اكتشاف استثناء غير مسجل أو استثناء من النظام الخارجي ، يجب تسجيل تفاصيل الاستثناء.
حاول {... string sql = "select * from userinfo" ؛ state s = con.createstatement () ؛ ... catch (sqlexception splex) {logger.error ("sql execution error"+sql+sqlex) ؛} مكان تسجيل معلومات الاستثناء وكيفية تسجيل معلومات الاستثناء قد تكون مسألة رأي. بعض الأنظمة حتى تسمح باستثناء فئة الاستثناءات. عند إنشاء كائن استثناء جديد ، يتم تسجيل معلومات الاستثناء تلقائيًا.
يمتد BusinessException من الفئة العامة الاستثناء {private void logtrace () {StringBuffer Buffer = new StringBuffer () ؛ buffer.append ("خطأ في العمل في الفئة:") ؛ buffer.append (getClassName ()) ؛ buffer.append ("، الطريقة:") "؛) يبدو أن هذا رائع للغاية ، لكنه سيؤدي حتماً إلى تسجيل الاستثناء مرارًا وتكرارًا. في الوقت نفسه ، فإنه ينتهك "مبدأ توزيع مسؤوليات الطبقات" وهو تصميم سيء. لا ينتمي تسجيلات التسجيل إلى سلوك فئة الاستثناء ، ويجب أن يتم تسجيل استثناءات من قبل نظام تسجيل خاص. ومعلومات التسجيل غير الطبيعية تتغير باستمرار. نحن نسجل استثناءات يجب أن تعطي معلومات أكثر ثراء. هذا يساعدنا على إيجاد السبب الجذري للمشكلة بناءً على معلومات الاستثناء لحل المشكلة.
على الرغم من أننا ناقشنا الكثير حول تسجيل الاستثناءات ، إلا أن التركيز كثيرًا على هذه يجعل المطورين أكثر إرباكًا. إحدى الطرق الجيدة هي توفير إطار معالجة الاستثناء للنظام. يقرر الإطار ما إذا كان سيتم تسجيل الاستثناءات وكيفية تسجيل الاستثناءات. الأمر ليس متروكًا للمبرمجين العاديين لتقريرهم. لكن من المفيد معرفة شيء ما.
5. الاستثناء معالجة في مشروع J2EE
في الوقت الحاضر ، تنقسم مشاريع J2EE بشكل عام إلى طبقات متعددة بشكل منطقي. تنقسم الطائرات الكلاسيكية إلى ثلاث طبقات: طبقة العرض ، طبقة الأعمال ، وطبقة التكامل (بما في ذلك الوصول إلى قاعدة البيانات والوصول إلى النظام الخارجي).
يعاني مشروع J2EE من تعقيده ، ويجب إيلاء اهتمام خاص للعديد من القضايا عند التعامل مع الاستثناءات في مشروع J2EE.
عند استخدام التطبيقات الموزعة ، نواجه العديد من الاستثناءات التي تم فحصها. جميع مكالمات RMI (بما في ذلك مكالمات الواجهة عن بعد EJB) ستلقي java.rmi.remoteexception ؛ في الوقت نفسه ، يعد RemoteException استثناءً محددًا. عندما نقوم بإجراء مكالمات عن بُعد في نظام الأعمال ، نحتاج جميعًا إلى كتابة كمية كبيرة من التعليمات البرمجية للتعامل مع هذه الاستثناءات التي تم فحصها. بمجرد حدوث RemoteException ، تكون هذه الاستثناءات التي تم فحصها خطيرة للغاية للنظام ، ولا يوجد أي إمكانية لإعادة المحاولة تقريبًا. وهذا يعني ، عندما تظهر هذه الاستثناءات الفظيعة التي تم فحصها من remoteexception ، لا نحتاج إلى إعادة المحاولة ، ولكن علينا أن نكتب الكثير من المحاولة ... Catch Code للتعامل معها. بشكل عام ، نجري مكالمات RMI في المستوى السفلي. طالما أن هناك مكالمة RMI ، فإن جميع واجهات المستوى العلوي ستتطلب إلقاء RemoteException. لأن الطريقة التي نتعامل بها مع RemoteException هي مواصلة رميها. هذا سوف يدمر واجهة أعمالنا. RemoteException هذه الاستثناءات على مستوى نظام J2EE تؤثر بشكل خطير على واجهات أعمالنا. الغرض من طبقاتنا للأنظمة هو تقليل الاعتماد بين الأنظمة ، ولن تؤثر التغييرات التكنولوجية في كل طبقة على طبقات أخرى.
.
وبالمثل ، فإن JDBC Access سوف يرمي استثناء محدد من Sqlexception.
من أجل تجنب التسلل العميق للاستثناءات التي تم فحصها على مستوى النظام في نظام الأعمال ، يمكننا تحديد استثناء نظام الأعمال الخاص بأسلوب العمل. للحصول على استثناءات خطيرة للغاية مثل SQLException و remoteexception ، يمكننا تحديد استثناء جديد غير محدد ، ثم تغليف sqlexception و remotexception إلى استثناء لم يتم التحقق منه ورميه.
إذا تم تسليم هذا الاستثناء على مستوى النظام إلى المتصل السابق للتعامل معه ، فيمكنك تحديد استثناء العمل المحدد حديثًا ، ثم قم بإغلاق استثناء مستوى النظام في استثناء على مستوى العمل ثم رميه.
بشكل عام ، نحتاج إلى تحديد استثناء لم يتم التحقق منه ، بحيث تعلن جميع طرق واجهة طبقة التكامل عن إلقاء هذا الاستثناء غير المحدد.
dataAccAccExceptionExtends public RunTimeException {...} واجهة عامة userDao {public string getPassword (string userId) يلقي dataAccessException ؛} الفئة العامة userDaoImplimples userDao {public string getPassword (string userId) يلقي dataAccessexception {string sql = " "+userId+" "؛ Try {... // jdbc calls s.executequery (sql) ؛ ...} catch (sqlexception ex) {throw dataAccessException (" فشل استعلام قاعدة البيانات "+sql ، ex) ؛}}}}}}}}} حدد استثناء العمل المحدد ، بحيث تعلن جميع أساليب واجهة طبقة العمل عن إلقاء استثناء محدد.
استثناء من الفئة العامة BusinessExceptionExtends {… ..} واجهة عامة usermanager {public userinfo copyUserInfo (userinfo user) يلقي businessException {userInfo newUser = null ؛ try {newUser = (userinfo) user.clone () ؛ مدعوم: "+userinfo.class.getName () ، ex) ؛}}} يجب أن تكون طبقة تمثيل J2EE طبقة رقيقة جدًا ، ووظائفها الرئيسية هي: الحصول على طلبات الصفحة ، وتجميع معلمات الصفحة في كائنات POJO ، واتصل بطرق العمل المقابلة ، ثم إعادة توجيه الصفحة ، وتقديم بيانات الأعمال المقابلة إلى الصفحة. تحتاج طبقة العرض التقديمي إلى الانتباه إلى قضية واحدة. تحتاج طبقة العرض التقديمي إلى التحقق من شرعية البيانات ، مثل بعض حقول الإدخال لا يمكن أن تكون فارغة ، والتحقق من طول الأحرف ، إلخ.
جميع المعلمات التي تم تمريرها من J2EE إلى الخلفية من الصفحة هي نوع الحرف. إذا كنت بحاجة إلى إدخال المعلمات العددية أو نوع التاريخ ، فيجب تحويل قيمة الحرف إلى القيمة العددية أو التاريخ المقابلة.
إذا كانت معلمات التحقق من رمز طبقة التمثيل غير صالحة ، فيجب إرجاعها إلى الصفحة الأصلية ، مما يسمح للمستخدم بإعادة إدخال البيانات ، والمطالبة بمعلومات الخطأ ذات الصلة.
عادة ، يتم تحويل المعلمة التي تم تمريرها من الصفحة إلى قيمة رقمية ، يمكننا رؤية مثل هذا الرمز
ModeAndView HandleRequest (HttPservletRequest request ، httpservletresponse) يلقي استثناء {string agestr = request.getParameter ("Age") ؛ int age = integer.parse (agestr) ؛ ……. تنسيق SimplEdateFormat = جديد SimplEdateFormat ("MM/DD/YYYY") ؛ تاريخ عيد ميلاد = format.parse (pritudystr) ؛} يجب رؤية الرمز أعلاه في كثير من الأحيان ، ولكن عندما يدخل المستخدم حرفًا لا يمكن تحويله إلى عدد صحيح من الصفحة أو قيمة تاريخ غير صحيحة.
يتم إلقاء طريقة integer.parse () استثناء غير محدد مع NumberFormatexception. ومع ذلك ، فإن هذا الاستثناء ليس بالتأكيد استثناء قاتل. بشكل عام ، عندما تكون القيمة التي يدخلها المستخدم في حقل إدخال الصفحة غير قانوني ، يجب أن نطالب المستخدم بإعادة الدخول. ولكن بمجرد إلقاء استثناء لم يتم التحقق منه ، لا توجد فرصة للمحاولة مرة أخرى. مثل هذه الرموز تتسبب في عرض قدر كبير من معلومات الاستثناء على الصفحة. اجعل نظامنا يبدو هشًا للغاية.
وبالمثل ، فإن طريقة SimpleDateFormat.Parse () ستلقي أيضًا استثناء غير محدد من ParseException.
في هذه الحالة ، يجب أن نلتقط هذه الاستثناءات غير المحددة ونطالب المستخدم بإعادة الدخول.
ModeAndView HandleRequest (طلب httpservletrequest ، httpservletresponse) يلقي الاستثناء {string agestr = request.getParameter ("العمر") ؛ سلسلة المواليد adaystr = request.getParameter ("عيد ميلاد") على سبيل المثال) {error.reject ("Age" ، "ليست قيمة عدد صحيح قانوني") ؛} ........................................................................................................................................................................................................................................................................................... تنسيق 'mm/dd/yyy') ؛}} في طبقة العرض التقديمي ، يجب عليك معرفة ما إذا كانت طريقة الاتصال ستلقي استثناءًا غير محدد ، تحت الظروف التي سيتم طرح هذه الاستثناءات ، وإجراء المعالجة الصحيحة.
في طبقة العرض التقديمي ، ليست هناك حاجة لالتقاط استثناءات بشكل عام. إذا كان الاستثناء الذي تم إلقاؤه بواسطة طريقة العمل المسمى يعادل قيمة الإرجاع الثانية ، في هذه الحالة ، من الضروري التقاط.
ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.