@ उपयोगी कब होता है?

Question

जैसा कि आप जानते हैं, @ एक php istruction से पहले अक्षर प्रत्येक अंतिम चेतावनी, त्रुटि या उठाए जाने से नोटिस दबाते हैं।

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

वैसे, मुझे यह तकनीक कई स्क्रिप्ट्स (सीएमएस प्लगइन्स, ओपन-सोर्स क्लासेस) में लागू करने के लिए मिलती है।

तो, क्या @ वास्तव में उपयोगी हो सकता है (इस मामले में, एक उदाहरण की सराहना की जाएगी), या सिर्फ आलसी डेवलपर्स के लिए है?

Answer 1

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

हालांकि PHP चेतावनी @ -sign के माध्यम से दबा दी गई थी, लेकिन आप बाद में उपयोगकर्ता को एक दोस्ताना त्रुटि संदेश दिखाने जैसे कुछ क्रियाएं कर सकते हैं।

हालांकि नीचे दिए गए उदाहरण में जैसी चीजों के लिए @ "दुरुपयोग" निश्चित रूप से एक अच्छा विचार नहीं है:

@$undefinedVariable .= 'some text'; 

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

Answer 2

मैं वास्तव में @ नापसंद करता हूं, लेकिन कभी-कभी कुछ सेटअप में यह अपरिहार्य है।

व्यक्तिगत रूप से मैं त्रुटियों को लॉग करने के लिए कॉन्फ़िगरेशन पर PHP सेट करना पसंद करता हूं और संदेशों को दबाने के लिए @ क्रच का उपयोग करने के बजाय उत्पादन सेटअप पर चुपचाप विफल रहता हूं।

अच्छा उपयोग: चेतावनियां। कभी-कभी कार्य चेतावनियां फेंकते हैं और वहां कुछ भी नहीं है जो आप बिना डिज़ाइन किए कर सकते हैं, लेकिन यह अभी भी ठीक से काम करता है। @ इसे दबाएगा।

Answer 3

आपके प्रश्न का उत्तर सरल और सीधा है: नहीं, @ बेकार है, और वास्तव में हानिकारक है, और इसका उपयोग नहीं किया जाना चाहिए। कभी नहीँ।

एकमात्र अपवाद जिसे मैं सोच सकता हूं, त्वरित "रन-वन" स्क्रिप्ट हैं, जब आपको वास्तव में कोड गुणवत्ता और शुद्धता की परवाह नहीं है।

उत्पादन स्क्रिप्ट में, मैं दुर्लभ मामलों में खाली catch ब्लॉक के साथ set_error_handler कि अपवादों में त्रुटियों बदल देता है, और try उपयोग करने का सुझाव था जब एक त्रुटि अनदेखा किया जाना चाहिए:

try { 
    unlink('tempfile'); 
} catch(Exception $e) { 
    // i don't care 
} 

Answer 4

वहाँ एक उपयोग के मामले है: आप तो scream का परीक्षण करना चाहते हैं, एक पीईसीएल एक्सटेंशन जो @ ऑपरेटर को अक्षम करता है। :)

Answer 5

मुझे थोड़ा देर हो चुकी है, लेकिन PHP में @ का उपयोग करना आम तौर पर एक अच्छा विचार नहीं है। मैं इसे केवल टेस्ट कोड के लिए उपयोग करता हूं और निश्चित रूप से उत्पादन के लिए नहीं।

त्रुटियों को संभालने का एक बेहतर तरीका set_error_handler फ़ंक्शन (http://ch.php.net/set_error_handler) का उपयोग कर रहा है। अगर कुछ गलत हो जाता है तो आप केवल त्रुटि लॉग कर सकते हैं (और शायद व्यवस्थापक को सूचित कर सकते हैं) और फिर उपयोगकर्ता को एक कस्टम त्रुटि संदेश प्रदर्शित कर सकते हैं या आप इसे केवल अनदेखा कर सकते हैं यदि यह केवल एक नोटिस/चेतावनी है। (आप शायद यह पहले से ही कर रहे हैं।)

और यह वह जगह है जहां @ फिर से काम में आता है। यदि आप एक कमांड में @ जोड़ते हैं और यह किसी भी तरह की त्रुटि का कारण बनता है, तो त्रुटि हैंडलर को वैसे भी कहा जाएगा, लेकिन पैरामीटर 'errno' शून्य पर सेट किया गया है। PHP त्रुटि स्तर (http://ch.php.net/manual/en/errorfunc.constants.php) के विभिन्न मानों की सूची देखें। उनमें से कोई भी शून्य के बराबर नहीं है, इसलिए आप @ के साथ फ़ंक्शंस में होने वाली त्रुटियों की पहचान कर सकते हैं। उदाहरण के लिए आप इसे "फ्लैग" महत्वहीन त्रुटियों के लिए उपयोग कर सकते हैं (जब आप निष्पादन को रोकना नहीं चाहते हैं, लेकिन इसे लॉग इन करना सुनिश्चित करें क्योंकि यह डिबगिंग के लिए सहायक हो सकता है) या किसी अन्य उद्देश्य के लिए इसका उपयोग करें।

Answer 6

केवल उपयोगी स्थिति होगा:

आप php/अपाचे config के लिए उपयोग नहीं है, तो और त्रुटियों उपयोगकर्ता के लिए प्रदर्शित कर रहे हैं।

अन्यथा, @... का उपयोग न करें और कुछ लॉग सिस्टम (फ़ाइल, डेटाबेस, आदि) में त्रुटियों (php/apache config में) को पुनर्निर्देशित करें।

पीएस: कुछ आधिकारिक PHP दस्तावेज़ों में, आप देख सकते हैं कि फ़ाइल मौजूद है या नहीं तो इसे हटाने के बजाय, वे बस @unlink इसे हटाते हैं। लेकिन मुझे यह पसंद नहीं है: मैं मुद्दे (एक्सेस अधिकार, इत्यादि) के मामले में अपने लॉग में त्रुटि प्राप्त करना पसंद करता हूं।