6

मैं Google ऐप इंजन (वेबपैप फ्रेमवर्क) पर एक प्रोजेक्ट विकसित कर रहा हूं। मुझे लोगों को यह आकलन करने की आवश्यकता है कि मैं अपवादों को कैसे संभालें।अपवादों को संभालने के लिए डिज़ाइन - Google ऐप इंजन

अपवाद मैं से निपटने कर रहा हूँ के 4 प्रकार के होते हैं:

  1. प्रोग्रामिंग अपवाद
  2. बुरा उपयोगकर्ता इनपुट
  3. गलत यूआरएल
  4. गलत क्वेरी स्ट्रिंग

यहाँ मैं कैसे संभाल है उन्हें:

  1. मैंने webapp.requesthandler क्लास को उपclassed है और handle_exceptions विधि को ओवरराइड किया है। जब भी कोई अपवाद होता है, तो मैं उपयोगकर्ता को एक दोस्ताना "हमें खेद है" पृष्ठ पर ले जाता है और इसके दौरान व्यवस्थापक को ट्रेसबैक के साथ एक संदेश भेजता है।

  2. क्लाइंट साइड पर मैं (एस) जेएस का उपयोग करता हूं और सर्वर की ओर भी मान्य करता हूं। प्रोग्रामिंग तर्क के अनुसार इनपुट मान्य करने के अलावा मैं (गैर-वेब अनुभव वाले कोडर के रूप में) (चेक: नकद इनपुट फ्लोट प्रकार का है?) और व्यवसाय नियम (जांच: उपयोगकर्ता के पास उस कार्रवाई को करने के लिए पर्याप्त अंक हैं?), मुझे भी दुर्भावनापूर्ण इरादों के खिलाफ जांच करनी है। दुर्भावनापूर्ण कार्रवाइयों के खिलाफ मुझे क्या उपाय करना चाहिए?

  3. मेरे पास एक पकड़-सब यूआरएल है जो गलत यूआरएल को संभालता है। यही कहना है, मैं उपयोगकर्ता को एक कस्टम "पृष्ठ मौजूद नहीं है" पृष्ठ पर ले जाता हूं। मुझे कोई समस्या नहीं है, मुझे लगता है।

  4. गलत क्वेरी स्ट्रिंग संभावित रूप से अपवादों को उठाते हैं यदि वे स्वयं को छोड़ देते हैं। यदि कोई आईडी मौजूद नहीं है, तो विधि कोई नहीं लौटाती है (रास्ते में एक अपवाद है)। यदि पैरामीटर असुविधाजनक है, तो कोड अपवाद उठाता है। यहां मुझे लगता है कि मुझे 404 जुटाना होगा और उपयोगकर्ता को कस्टम "पृष्ठ मौजूद नहीं है" पृष्ठ पर ले जाना चाहिए। मुझे क्या करना चाहिए?

आपकी राय क्या हैं? अग्रिम धन्यवाद ..

+1

क्लाइंट साइड पर दुर्भावनापूर्ण इनपुट के लिए सत्यापन करने में कोई बात नहीं है - कोई भी दुर्भावनापूर्ण उपयोगकर्ता इसे अक्षम या बर्बाद कर देगा। –

+0

ठीक है, मैं सर्वर पक्ष पर क्या करूँ? – shanyu

उत्तर

5

आपने बहुत अच्छी तरह से चीजों को सोचा है। एकमात्र चीज जो मैं जोड़ूंगा वह यह है कि आप उदाहरण के रूप में Bloog पर एक नज़र डालना चाहेंगे। ब्लूग पाइथन में लिखे गए ऐप इंजन के लिए एक बहुत अच्छी तरह लिखित और लोकप्रिय ओपन सोर्स ब्लॉग इंजन है।

इसके अलावा, प्वाइंट # 2 पर हमलों के these types के लिए देखें।

# 4 के लिए, ध्यान रखें कि 404 पृष्ठ आपके डिजाइन में color and creativity जोड़ने का अवसर हैं।

+0

धन्यवाद, मैं करूँगा। अंक 2 और 4 पर कोई सुझाव? – shanyu

+0

मैंने # 2 और # 4 पर कुछ टिप्पणियां जोड़ने के लिए अपनी प्रतिक्रिया अपडेट की। ऐसा लगता है कि आप इसे पहले से ही अच्छी तरह से सोचा है। – Serx

+0

धन्यवाद, फिर से। मैं आपके द्वारा प्रदान किए गए लिंक से गुज़र जाऊंगा। – shanyu

0

विज्ञापन। # 4: मैं आमतौर पर क्वेरी स्ट्रिंग को गैर-आवश्यक के रूप में मानता हूं। यदि क्वेरी स्ट्रिंग के साथ कुछ भी गलत है, तो मैं केवल नंगे संसाधन पृष्ठ (जैसे कि कोई क्वेरी मौजूद नहीं थी), संभवतः उपयोगकर्ता को कुछ जानकारी के साथ क्वेरी स्ट्रिंग के साथ क्या गलत था।

इससे आपके # 3 की तरह की समस्या होती है: उपयोगकर्ता को इस गलत क्वेरी में कैसे मिला? क्या मेरा एप्लिकेशन कहीं गलत यूआरएल उत्पन्न करता है? या क्या यह किसी बाहरी सेवा, या सहेजे गए बुकमार्क में पुराना लिंक था? HTTP_REFERER में कुछ सुराग हो सकता है, लेकिन निश्चित रूप से आधिकारिक नहीं है, इसलिए मैं समस्याग्रस्त क्वेरी (कुछ अतिरिक्त HTTP शीर्षलेखों के साथ) लॉग इन करता हूं और मामले की जांच करने का प्रयास करता हूं।

+0

उत्तर के लिए धन्यवाद। मुझे लगता है कि बिंदु 3 की ओर जाने वाले कारणों में से एक यह है कि उपयोगकर्ता क्वेरीस्ट्रिंग को संशोधित करके कुछ "अनावश्यक" कोशिश करता है। – shanyu