MVC का उपयोग करते समय PHP में त्रुटियों को संभालना

Question

मैं हाल ही में कोडिग्नेटर का उपयोग कर रहा हूं, लेकिन एक चीज जो मेरी नसों पर मिलती है, त्रुटियों को संभाल रही है और उन्हें उपयोगकर्ता को प्रदर्शित कर रही है। मैं त्रुटियों के बिना कभी भी गड़बड़ करने में अच्छा नहीं रहा। मेरी मुख्य चिंता उपयोगकर्ता को त्रुटियों को वापस करते समय है।

क्या फ़ंक्शंस से 0 या 1 वापस करने के बजाय अपवादों को फेंकना / पकड़ना / पकड़ना और फिर त्रुटियों को संभालने के लिए if / else का उपयोग करना अच्छा अभ्यास है। इस प्रकार, उपयोगकर्ता को समस्या के बारे में सूचित करना आसान बनाता है।

मैं अपवादों से दूर जाता हूं। कुछ साल पहले विश्वविद्यालय में मेरे जावा ट्यूटर ने मुझे बताया था कि "डिबगिंग के लिए अधिक उत्पादन कोड में अपवादों का उपयोग नहीं किया जाना चाहिए"। मुझे लग रहा है कि वह झूठ बोल रहा था।

लेकिन, एक उदाहरण, मेरे पास एक कोड है जो एक उपयोगकर्ता को डेटाबेस में जोड़ता है। प्रक्रिया के दौरान 1 से अधिक चीजें गलत हो सकती हैं, जैसे कि डेटाबेस समस्या, डुप्लिकेट प्रविष्टि, सर्वर समस्या, आदि जब पंजीकरण के दौरान कोई समस्या होती है तो उपयोगकर्ता को इसके बारे में जानने की आवश्यकता होती है।

PHP में त्रुटियों को संभालने का सबसे अच्छा तरीका क्या है, इस बात को ध्यान में रखते हुए कि मैं MVC फ्रेमवर्क का उपयोग कर रहा हूं।

Answer 1

क्या फ़ंक्शंस से 0 या 1 वापस करने के बजाय अपवादों को फेंकना / पकड़ना / पकड़ना और फिर त्रुटियों को संभालने के लिए if / else का उपयोग करना अच्छा अभ्यास है। इस प्रकार, उपयोगकर्ता को समस्या के बारे में सूचित करना आसान बनाता है।

नहीं नहीं नहीं!

अपवाद और त्रुटियों का मिश्रण न करें। अपवाद, अच्छी तरह से, असाधारण हैं। त्रुटियां नहीं हैं। जब आप किसी उपयोगकर्ता को किसी उत्पाद की मात्रा दर्ज करने के लिए कहते हैं, और उपयोगकर्ता "हैलो" में प्रवेश करता है, तो यह एक त्रुटि है। यह अपवाद नहीं है: उपयोगकर्ता से अमान्य इनपुट देखने में कुछ भी असाधारण नहीं है। इनपुट को मान्य करते समय आप गैर-असाधारण मामलों में अपवादों का उपयोग क्यों नहीं कर सकते? अन्य लोगों ने इसे पहले से ही समझाया, और इनपुट सत्यापन के लिए एक वैध विकल्प दिखाया।

इसका अर्थ यह भी है कि उपयोगकर्ता आपके अपवादों की परवाह नहीं करता है , और अपवादों को दिखाना अपरिहार्य और खतरनाक दोनों है । उदाहरण के लिए, SQL क्वेरी के निष्पादन के दौरान एक अपवाद अक्सर क्वेरी को ही प्रकट करता है। क्या आप वाकई इस तरह के संदेश को सभी को दिखाने के लिए जोखिम लेना चाहते हैं?

1 से अधिक चीजें गलत हो सकती हैं, जैसे कि डेटाबेस समस्या, डुप्लिकेट प्रविष्टि, सर्वर समस्या, आदि जब पंजीकरण के दौरान कोई समस्या होती है तो उपयोगकर्ता को इसके बारे में जानने की आवश्यकता होती है।

गलत। एक उपयोगकर्ता के रूप में, मुझे आपके डेटाबेस मुद्दों, डुप्लिकेट प्रविष्टियों आदि को जानने की आवश्यकता नहीं है, मैं वास्तव में आपकी समस्याओं की परवाह नहीं करता हूं । मुझे यह जानने की आवश्यकता है कि मैंने एक उपयोगकर्ता नाम दर्ज किया है जो पहले से मौजूद है। जैसा कि पहले ही कहा गया है, मुझसे गलत इनपुट को एक त्रुटि को ट्रिगर करना चाहिए, अपवाद नहीं।

उन त्रुटियों को कैसे आउटपुट करें? ये संदर्भ पर निर्भर करता है। पहले से ही उपयोग किए जाने वाले उपयोगकर्ता नाम के लिए, मैं उपयोगकर्ता नाम के पास एक छोटा लाल झंडा देखना चाहता हूं, यहां तक ​​कि फॉर्म सबमिट करने से पहले, यह कहते हुए कि उपयोगकर्ता नाम पहले से ही उपयोग किया गया है। जावास्क्रिप्ट के साथ, एक ही ध्वज प्रस्तुत करने के बाद दिखाई देना चाहिए।

अन्य त्रुटियों के लिए, आप एक त्रुटि के साथ एक पूर्ण पृष्ठ दिखाएंगे, या उपयोगकर्ता को सूचित करने के लिए एक और तरीका चुनेंगे कि कुछ गलत हो गया था (उदाहरण के लिए एक संदेश जो दिखाई देगा, फिर पृष्ठ के शीर्ष पर दूर हो जाएगा)। सवाल तो प्रोग्रामिंग से उपयोगकर्ता अनुभव से संबंधित है।

प्रोग्रामर के दृष्टिकोण से, त्रुटि के प्रकार के आधार पर, आप इसे विभिन्न तरीकों से प्रचारित करेंगे। उदाहरण के लिए, पहले से ही उपयोग किए गए उपयोगकर्ता नाम के मामले में, AJAX अनुरोध http://example.com/?ajax=1&user-exists=Johnयह दर्शाता है कि एक JSON ऑब्जेक्ट लौटाएगा:

• उपयोगकर्ता पहले से मौजूद है,
• उपयोगकर्ता को दिखाने के लिए त्रुटि संदेश।

दूसरा बिंदु महत्वपूर्ण है: आप सुनिश्चित होना चाहते हैं कि जावास्क्रिप्ट अक्षम के साथ फ़ॉर्म सबमिट करते समय और जावास्क्रिप्ट सक्षम के साथ डुप्लिकेट उपयोगकर्ता नाम टाइप करते समय एक ही संदेश दोनों दिखाई दें। आप सर्वर-साइड स्रोत कोड और जावास्क्रिप्ट में त्रुटि संदेश के पाठ की नकल नहीं करना चाहते हैं!

यह वास्तव में Stack Exhange वेबसाइटों द्वारा उपयोग की जाने वाली तकनीक है। उदाहरण के लिए अगर मैं अपने स्वयं के उत्तर को उभारने की कोशिश करता हूं, तो AJAX प्रतिक्रिया में प्रदर्शित करने की त्रुटि होती है:

{"Success":false,"Warning":false,"NewScore":0,"Message":"You can't vote for your own post.",
"Refresh":false}

आप एक अन्य दृष्टिकोण भी चुन सकते हैं, और फ़ॉर्म भरने से पहले HTML पेज में त्रुटियों को निर्धारित कर सकते हैं। पेशेवरों: आपको AJAX प्रतिक्रिया में त्रुटि संदेश भेजने की आवश्यकता नहीं है। विपक्ष: पहुँच क्षमता के बारे में क्या? सीएसएस के बिना पृष्ठ ब्राउज़ करने का प्रयास करें, और आप देखेंगे कि सभी संभावित त्रुटियां दिखाई देंगी।

Comments

मैं प्रतिक्रिया की सराहना करता हूं। यह वही है जिससे मैं जूझ रहा हूं। क्या आपके पास रिपोर्टिंग त्रुटियों पर विशेष रूप से उपयोगकर्ता अनुभव के संदर्भ में कोई संसाधन हैं?

— जेम्स जेफ़री

खैर, जैसा मैंने कहा, यह वास्तव में त्रुटि पर निर्भर करता है, और उपयोगकर्ता को त्रुटियों की रिपोर्टिंग उपयोगकर्ता इंटरफ़ेस से दृढ़ता से जुड़ी हुई है। मैंने त्रुटियों की रिपोर्ट करने के दो मुख्य तरीकों पर भी प्रकाश डाला: तंग एकीकरण (गलत मान के साथ इनपुट के पास एक AJAX- सक्षम लाल झंडा) और पूर्ण पृष्ठ की त्रुटियां, बहुत कम अनुकूल, अधिक गंभीर मामलों के लिए उपयोग किया जाता है। क्या यह आपके प्रश्न का उत्तर नहीं देता है?

— आर्सेनी मौरज़ेंको

+1 इसके लिए अधिक उपयोगकर्ता अनुभव का मुद्दा है और तकनीकी नहीं है

— चार्ल्स स्प्रेबेरी

बुलशिट, मेनमा। बस बकवास है। एररकोड 80 और 90 के दशक के हैं। अपवाद विशेष परिस्थितियों को संभालने के लिए एक बहुत अधिक स्वच्छ तरीका है जैसे गलत इनपुट (उदाहरण के लिए सत्यापन)। आप उपयोगकर्ता को हर अपवाद प्रदर्शित करने के लिए मजबूर नहीं हैं। मैंने आपके बेहतर उत्तर देखे हैं।

— फाल्कन

और बस अगर आप इसे नहीं जानते हैं: आप नियंत्रित कर सकते हैं कि आप किन अपवादों को उपयोगकर्ता के सामने प्रस्तुत करना चाहते हैं और जिन्हें आप प्रस्तुत नहीं करना चाहते हैं। तो यह वास्तव में एक तर्क नहीं है।

— फाल्कन

Answer 2

क्या फ़ंक्शंस से 0 या 1 वापस करने के बजाय अपवादों को फेंकना / पकड़ना / पकड़ना और फिर त्रुटियों को संभालने के लिए if / else का उपयोग करना अच्छा अभ्यास है। इस प्रकार, उपयोगकर्ता को समस्या के बारे में सूचित करना आसान बनाता है।

हाँ हाँ हाँ!

यदि आप स्वच्छ कोड रखना चाहते हैं, तो आपको लगभग विशेष रूप से अपवादों का उपयोग करना चाहिए और त्रुटि कोड का उपयोग करके परेशान नहीं करना चाहिए। त्रुटि कोड अर्थहीन हैं। वे लगभग हमेशा कुछ संख्यात्मक स्थिरांक से बंधे होते हैं जो बहुत अधिक जानकारी का खुलासा नहीं करते हैं। यह आपके कोड को अपठनीय बना सकता है और वे त्रुटि के साथ डेटा का प्रचार करना कठिन बना देंगे।

अपवाद, हालांकि, कक्षाएं हैं और आपकी पसंद की कोई भी जानकारी हो सकती है। इसलिए उपयोगकर्ता ने एक गलत इनपुट दर्ज किया, जैसे एक नंबर फ़ील्ड के लिए 'एबीसी'। एक त्रुटि कोड के साथ आप इस जानकारी को बहुत अधिक बुदबुदाहट के बिना त्रुटि के हैंडलर को प्रसारित करने में सक्षम नहीं होंगे। कुछ ऐसा जो अपवादों को मुफ्त में प्रदान करता है। इसके अलावा, अपवाद आपको कार्यों और विधियों में सार्थक वापसी मूल्यों की अनुमति देते हैं जबकि अभी भी सुरुचिपूर्ण ढंग से विफल होने का एक तरीका है। इससे भी बेहतर, अपवादों को उस जगह पर प्रचारित किया जाता है, जहाँ आप उन्हें संभालना चाहते हैं! स्पेगेटी कोड की मात्रा की कल्पना करें आपको ऊपर एक या दो परतों के लिए सार्थक डेटा के साथ एक त्रुटि कोड का प्रसार करने की आवश्यकता होगी।

इसके अलावा, अपवाद त्रुटि कोड की तुलना में बहुत अधिक शब्दार्थ व्यक्त करते हैं। एररकोड्स स्पेगेटी कोड की ओर ले जाते हैं जहां अपवाद हैंडलिंग साफ कोड की ओर जाता है।

इसके अलावा, स्टेटस कोड्स को जांचना भूल जाना आसान है। जावा जैसी भाषाओं में आपको अपवादों को संभालने के लिए मजबूर किया जाता है (उदाहरण के लिए C # misses)।

PHP में त्रुटियों को संभालने का सबसे अच्छा तरीका क्या है, इस बात को ध्यान में रखते हुए कि मैं MVC फ्रेमवर्क का उपयोग कर रहा हूं।

अपवादों का उपयोग करें और उन्हें अपने नियंत्रकों में संभालें।

Comments

मैं आपसे बहुत सहमत हूँ !! अलग-अलग अपवाद अन्य भाषाओं की तरह PHP लागू नहीं किए गए हैं, यह जानना अच्छा है कि बहुत से लोग उन्हें परेशान कर रहे हैं ...

— डेविड कोन

मैं मानता हूं कि ज्यादातर मामलों में त्रुटि कोड काफी अर्थहीन होते हैं। हालांकि, अपवादों को नीली फेंकना बेहद बुरा है! अपवाद केवल असाधारण परिस्थितियों के लिए आरक्षित होने चाहिए। अपवाद अप्रत्याशित प्रोग्राम प्रवाह का कारण बनते हैं, कोड को (और इसलिए बनाए रखने के लिए) का पालन करना कठिन बना सकते हैं, और PHP में वे IF / THEN / ELSE की तुलना में एक महत्वपूर्ण प्रदर्शन जुर्माना लगाते हैं। मैं सफलता पर सच्चा लौटने के लिए, असफलता पर झूठ बोलने के तरीकों को प्राथमिकता देता हूं, और केवल कुछ अपवाद छोड़ देता हूं, जैसे कि गलत है।

— गॉर्डन

Answer 3

इस आसान छोटी कक्षा पर विचार करें:

class FunkyFile {               

    private $path;
    private $contents = null;

    public function __construct($path) { 
        $this->setPath($path); 
    }

    private function setPath($path) {
        if( !is_file($path) || !is_readable($path) ) 
            throw new \InvalidArgumentException("Hm, that's not a valid file!");

        $this->path = realpath($path);
        return $this; 
    }

    public function getContents() {
        if( is_null($this->contents) ) {
            $this->contents = @file_get_contents( $this->path );
            if($this->contents === false) 
                throw new \Exception("Hm, I can't read the file, for some reason!");                                 
        }

        return $this->contents;            
    }

}

यह अपवादों का बिल्कुल ठीक उपयोग है। FunkyFile'sयदि कोई रास्ता या तो अमान्य है या file_get_contentsविफल रहता है, तो परिप्रेक्ष्य से पूरी तरह से कुछ भी नहीं किया जा सकता है । वास्तव में असाधारण स्थिति;)

लेकिन क्या आपके उपयोगकर्ता के लिए यह जानने का कोई मूल्य है कि आपने अपने कोड में कहीं गलत फ़ाइल पथ पर ठोकर खाई है? उदाहरण के लिए:

class Welcome extends Controller {

    public function index() {

        /**
         * Ah, let's show user this file she asked for
         */                 
        try {
            $file = new File("HelloWorld.txt");
            $contents = $file->getContents();   
            echo $contents;
        } catch(\Exception $e) {
            log($e->getMessage());

            echo "Sorry, I'm having a bad day!"; 
        }                           
    }        
}

उन लोगों के बारे में बताने के अलावा, जिनसे आपका बुरा दिन चल रहा है, आपके विकल्प हैं:

1. मैदान छोड़ना

   क्या आपके पास जानकारी प्राप्त करने का एक और तरीका है? ऊपर मेरे सरल उदाहरण में, यह संभावना नहीं लगती है, लेकिन एक मास्टर / दास डेटाबेस स्कीमा पर विचार करें। मास्टर जवाब देने में विफल हो सकता है, लेकिन हो सकता है, बस हो सकता है, दास अभी भी बाहर है (या इसके विपरीत)।

2. क्या यह उपयोगकर्ता की गलती है?

   क्या उपयोगकर्ता ने दोषपूर्ण इनपुट सबमिट किया है? खैर, उसे इसके बारे में बताएं। आप या तो एक त्रुटि संदेश लिख सकते हैं, या अच्छा हो सकते हैं और उस त्रुटि संदेश को एक फॉर्म के साथ भेज सकते हैं ताकि वह सही रास्ते में टाइप कर सके।

3. क्या यह आपकी गलती है?

   और आपके द्वारा, मेरा मतलब कुछ भी है जो उपयोगकर्ता नहीं है, ताकि आपके द्वारा गलत फ़ाइल पथ टाइप करने से लेकर आपके सर्वर में कुछ गड़बड़ हो जाए। सख्ती से, यह 503 HTTP त्रुटि के लिए समय है , साथ ही, सेवा अनुपलब्ध है। CI में एक show_404()फ़ंक्शन है, आप आसानी से बना सकते हैं show_503()।

सलाह का शब्द, आपको दुष्ट अपवादों को ध्यान में रखना चाहिए। CodeIgniter कोड का एक गन्दा टुकड़ा है, और आप कभी नहीं जानते कि कोई अपवाद कब पॉप अप होगा। इसी तरह, आप अपने स्वयं के अपवादों के बारे में भूल सकते हैं, और सबसे सुरक्षित विकल्प एक पकड़ सभी अपवाद हैंडलर को लागू करना है। PHP में आप set_exception_handler के साथ ऐसा कर सकते हैं :

function FunkyExceptionHandler($exception) {
    if(ENVIRONMENT == "production") {
        log($e->getMessage());
        show_503();
    } else {
        echo "Uncaught exception: " , $exception->getMessage(), "\n";
    }   
}

set_exception_handler("FunkyExceptionHandler");

और आप set_error_handler के माध्यम से दुष्ट त्रुटियों का भी ध्यान रख सकते हैं । आप या तो अपवादों के लिए एक ही हैंडलर लिख सकते हैं, या वैकल्पिक रूप से सभी त्रुटियों को बदल सकते हैं ErrorExceptionऔर अपने अपवाद हैंडलर को उनके साथ सौदा कर सकते हैं:

function FunkyErrorHandler($errno, $errstr, $errfile, $errline) {
    // will be caught by FunkyExceptionHandler if not handled
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}

set_error_handler("FunkyErrorHandler");

Comments

यह वास्तव में जानकारीपूर्ण था, चीयर्स!

— जेम्स