2011-03-24 2 views
5

तो मैंने अभी पढ़ा है Why to never use 'or die'.कैसे कृपा से मरने के लिए?

मैं अब और अधिक उलझन में हूं। मैं एक जटिल रूप को मान्य कर रहा हूं और मैं कहता हूं कि अगर बयानों के कई घोंसले के स्तर और मैं क्या नहीं कर रहा हूं और मैं उस रूप में एक वैरिएबल पास कर रहा हूं जिसे $ स्थिति कहा जाता है जो केवल 'नया' या 'संपादन' हो सकता है। फिर जब उपयोगकर्ता फॉर्म को फिर से सत्यापित करने के लिए सबमिट करता है तो फॉर्म $ स्थिति मूल्य के साथ एक छिपे हुए फ़ील्ड ($ _POST) के रूप में गुजरता है। मैं यह सुनिश्चित करना चाहता हूं कि उपयोगकर्ता गलती से इसे परिवर्तित नहीं कर सकता है, इसलिए मैं त्रुटि को पकड़ना चाहता हूं, हालांकि 'नया' या 'संपादन' पास के अलावा कुछ और होना चाहिए। (हालांकि मैं पूरी तरह से एक आदर्श दुनिया में इस चर को प्रभावित करने वाले उपयोगकर्ता की संभावना को दूर करना चाहते हैं।)

तो मैं सोचा कि मैं एक में मर जाते हैं() का प्रयोग करेंगे अगर बयान

<nested ifs> 
    Select ($status){ 
     Case 'edit': 
      break; 
     Case 'new': 
      break; 
     default: 
      //using example from article 
      trigger_error("An error that should not occur has occurred", E_USER_ERROR); 
      break; 
    } 
</nested ifs> 

मैं डॉन ' टी वास्तव में समझ में नहीं आता कि यह मरने से कैसे साफ है()? अनिवार्य रूप से मैं एक और फ़ंक्शन कॉल करना चाहता हूं जो उपयोगकर्ता को त्रुटि को ठीक करने के लिए इस समय पर कुछ विकल्प दिखा सकता है, लेकिन मैं चाहता हूं कि कोड पूरी तरह से चलना बंद कर दे क्योंकि मैं नहीं चाहता कि अगर कोई स्टेटमेंट पार्सिंग जारी रखने के लिए आगे बढ़ता है कुछ भी और एक त्रुटि उत्पन्न करते समय इसे 'नया' या 'संपादन' के अलावा कुछ और मिलता है।

मुझे यकीन नहीं है कि मैं कितना स्पष्ट हूं, कृपया मुझे किसी भी अस्पष्ट बिंदुओं पर विस्तार से पूछने के लिए स्वतंत्र महसूस करें। (या बेहतर अभी तक, क्या एक छिपी हुई उपयोगकर्ता फ़ील्ड हैक हो सकती है? कैसे रोकें?: पी)

+6

+1 अद्भुत शीर्षक। –

उत्तर

6

trigger_error() एक त्रुटि हैंडलर द्वारा प्रबंधित की गई त्रुटि को ट्रिगर करता है।

trigger_error() आप शान से उदाहरण के लिए, त्रुटियों संभाल कर सकते हैं के साथ

:

set_error_handler('ErrorHandler'); 

    function ErrorHandler($errno, $errmsg, $filename, $linenum, $vars) 
    { 
    print '<pre style="line-height: 2em;">'; 
    printf("==> Error in `%s' line %s: %s\n\n", $filename, $linenum, $errmsg); 
    debug_print_backtrace(); 
    print '</pre>'; 

    exit($errno); 
    } 

यह एक सरल उदाहरण है, लेकिन हमारी कंपनी की वेबसाइट के लिए एक अनुकूल त्रुटि पृष्ठ प्रदर्शित करता है और मुझे एक ईमेल कि मैं एक बेवकूफ और गड़बड़ कर रहा हूँ भेजता है ऊपर कहीं :-)

लाभ die() या exit() से अधिक होना चाहिए स्पष्ट :-)

exit() अभी भी इस्तेमाल किया जा सकता है जब आप बाहर निकलने के लिए की जरूरत है। उदाहरण के लिए जब आप एक टेम्पलेट जेनरेट करते हैं, आउटपुट करते हैं, और कोड निष्पादन को रोकना चाहते हैं। या जब आप header('Location: ...'); शीर्षलेख भेजते हैं और यह सुनिश्चित करना चाहते हैं कि निष्पादन बंद हो गया है ... बस अप्रत्याशित स्थितियों (यानी त्रुटियों) को संभालने के लिए इसका उपयोग न करें।

trigger_error() आपको भी बेहतर नियंत्रण प्रदान करता है। जब आप निष्पादन रोकना चाहते हैं तो E_USER_NOTICE भेज सकते हैं लेकिन नोटिस प्रदर्शित कर सकते हैं, और जब आप पर रोक लगाना चाहते हैं रोकें।

इसके अलावा, आप अधिक जटिल त्रुटि हैंडलर फ़ंक्शंस लिख सकते हैं जहां कुछ आईपी में कोई त्रुटि दिखाई देती है, और बाकी नहीं ... Kindda विकास के लिए उपयोगी है।

हालांकि अधिक जटिल त्रुटि हैंडलर के साथ सावधान रहें, हालांकि, एक त्रुटि हैंडलर के अंदर कोई त्रुटि होती है ...?आप स्थापना के समय :)

+0

ट्रिगर_error() इस में फिट कहां है? क्या ट्रिगर त्रुटि फ़ंक्शन set_error_handler को कॉल करता है जो बदले में ErrorHandler को कॉल करता है? जिस तरह से मैं इस कोड को प्रशंसा के साथ देख रहा हूं: "ओएच इतनी चमकदार": डी – Mallow

+1

@ मॉलो: यही वही होता है। 'Set_error_handler' के बारे में सबसे अच्छी बात यह है कि आप वास्तव में विभिन्न (हैंडलबल) त्रुटि प्रकारों के लिए एकाधिक हैंडलर सेट कर सकते हैं। देखें, कुछ त्रुटियों को पार्स त्रुटियों की तरह संभाला नहीं जा सकता है। – Charles

+0

यह अद्भुत है! आपने लापता लिंक पूरा कर लिया है। – Mallow

1

लेख आपको से जुड़ा हुआ बताता है कि क्यों आप or die उपयोग नहीं करना चाहिए, के रूप में देखा हो सकता है:

$result = mysql_query($query) or die('A MySQL query occurred: ' . mysql_error()); 

जाहिर इस एक बुरा विचार है, यह कर सकता है उत्पादन संवेदनशील जानकारी आपके MySQL संरचना के बारे में एक दुर्भावनापूर्ण उपयोगकर्ता को।

हालांकि, मुझे लगता है कि कुछ भी गलत नहीं है (और मुझे लगता है कि लेख का लेखक मुझसे सहमत होगा) die का उपयोग करने के तरीके में उपयोग करने के लिए, हालांकि विकल्पों की सूची के साथ उपयोगकर्ता को प्रस्तुत करना वास्तव में, इसे संभालने का पसंदीदा तरीका बनें।

+0

आह मुझे संदेह था कि 'या मर' उसका प्राथमिक ध्यान था, लेकिन मैं अपना हाथ आग में नहीं रखना चाहता था। – Mallow

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^