क्या त्रुटि खराब अभ्यास को दबा रही है?

Question

एसओ के सवाल पर मैंने यहां कुछ कोड के बारे में पूछा था जिनके बारे में मैं अनिश्चित था, किसी ने उत्तर दिया "बीटीडब्ल्यू, भयानक कोड: यह प्रतीक (@) को दबाने वाली त्रुटि का उपयोग करता है।"

क्या कोई कारण है कि यह बुरा व्यवहार क्यों है? चीजों के साथ:

$db=@new mysqli($db_info) or die('Database error');

, यह मुझे सिर्फ एक कस्टम त्रुटि संदेश प्रदर्शित करने की अनुमति देता है। दबाने के बिना, तब यह अभी भी विशिष्ट PHP संदेश प्रदर्शित करेगा:

चेतावनी : mysqli :: mysqli (): php_network_getaddresses: getaddrinfo विफल: ऐसा कोई होस्ट ज्ञात नहीं है। में कुछ \ फ़ाइल \ पथ पर लाइन 6

साथ ही 'डेटाबेस त्रुटि'।

क्या त्रुटि हमेशा खराब होती है, और यदि हां, तो विशेष रूप से उपरोक्त के बारे में क्या बुरा है?

अद्यतन: वास्तविक कोड जो मैं उपयोग कर रहा हूं वह है:

or error('Datatabase error', 'An error occurred with the database' . (($debug_mode) ? '<br />MySQL reported: <b>' . $db->error . '</b><br />Error occurred on line <b>' . __LINE__ . '</b> of <b>' . __FILE__ . '</b>' : ''))

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

Comments

जब आप खराब प्रैक्टिस कर रहे हों, तो क्या वह आंखों पर पट्टी बांध रहा है?

— डेमियन रोशे

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

— कुछ फ्री मेसन

@SomeFreeMason अगर मुझे डिबग करने की आवश्यकता है, तो मैं सिर्फ TRUE_mode को TRUE पर सेट करूंगा, क्योंकि मैं जो वास्तविक कोड उपयोग कर रहा हूं, वह है:or error('Datatabase error', 'An error occurred with the database' . (($debug_mode) ? '<br />MySQL reported: <b>' . $db->error . '</b>' : ''))

@Paradoxical: मुझे एहसास है कि PHP में अपवाद / त्रुटि से निपटने की स्थिति थोड़ी FUBAR है, लेकिन आप जानते हैं कि आप अपने PHP कॉन्फ़िगरेशन में त्रुटियों के दृश्य प्रदर्शन को बंद कर सकते हैं, है ना?

— फोशी

@Phoshi दुर्भाग्य से जो होस्टिंग सेवा मैं उपयोग कर रहा हूँ, वह मुझे php.ini तक नहीं

Answer 1

मुझे लगता है कि आप त्रुटि को दबाकर सही काम कर रहे हैं, क्योंकि आप स्वयं की त्रुटि से निपटने का कार्यान्वयन कर रहे हैं।

जावा के समकक्ष, इस पर विचार करना आसान हो सकता है। त्रुटि का उपयोग @करना एक अपवाद को निगलने के अनुरूप है। निम्नलिखित कोड, जो आपके समान है, उचित है:

try {
    db = new MySQLi(dbInfo);
} catch (SQLException connectionFailure) {
    die("Database error");
}

(खैर, जावा में, आप नहीं चाहेंगे कि सर्वलेट इंजन मर जाए, लेकिन आपको यह विचार मिल जाएगा।)

हालाँकि, यह स्वीकार्य नहीं है:

try {
    db = new MySQLi(dbInfo);
} catch (Exception e) {
}

अधिकांश PHP त्रुटि दमन लापरवाही से किया जाता है, बाद के उदाहरण के अनुरूप, इसलिए आपके कोड के खिलाफ घुटने-झटका प्रतिक्रिया।

Comments

मैं अपवाद को पकड़ना नहीं कहूंगा और सिर्फ निष्पादन को रोकना "संभालना" होगा। यदि आप समस्या को हल कर सकते हैं, महान, ऐसा करें। यदि आप नहीं कर सकते हैं, तो आप इसे क्या कर रहे हैं? यह वही है जिसके लिए हमारे पास शीर्ष स्तर के अपवाद हैंडलर हैं। इस मामले में अपवादों को पकड़ना सिर्फ यह सुनिश्चित कर रहा है कि आपके पास अपने कोडबेस पर जमा त्रुटि कोड है।

— फॉशी

Answer 2

त्रुटि दमन बुरा है, क्योंकि यह न केवल आपके द्वारा पहले से ज्ञात जानकारी को छिपाता है ( कुछ गलत हो गया)। यह डीबगिंग के लिए महत्वपूर्ण जानकारी भी छिपा सकता है, जिसके बारे में आपको जानकारी नहीं है ( क्या , कहाँ और क्यों )।

इस विशिष्ट उदाहरण में, " डेटाबेस त्रुटि " एक बहुत अच्छा त्रुटि संदेश नहीं है। डीबी के साथ कुछ गलत हुआ। बहुत ज्ञानवर्धक नहीं। " चेतावनी: mysqli :: mysqli (): php_network_getaddresses: getaddrinfo विफल: ऐसा कोई होस्ट ज्ञात नहीं है। लाइन 6 पर कुछ \ file \ path में वास्तव में एक बेहतर त्रुटि संदेश है। यह आपको समस्या के लिए एक स्थान और कारण देता है। आप सही में कूद सकते हैं और डिबगिंग शुरू कर सकते हैं, क्योंकि त्रुटि पहले से ही स्थित है।

बेशक, पुस्तकालय डिजाइनरों में कभी-कभी कई अप्रासंगिक चेतावनियों को लाने की प्रवृत्ति होती है। मैं PHP को पर्याप्त रूप से अच्छी तरह से नहीं जानता कि क्या यह चेतावनी को फ़िल्टर करने का एक तरीका है जिसमें आप रुचि नहीं रखते हैं। मुझे पता है कि सौ-पंक्ति स्टैकट्रेस के माध्यम से पढ़ना बहुत ज्ञानवर्धक नहीं है। लेकिन बहुत अधिक जानकारी के लिए सही प्रतिक्रिया शून्य करने के लिए जानकारी की मात्रा को कम करने के लिए नहीं है , लेकिन कुछ स्तर पर अप्रासंगिक भागों को फ़िल्टर करने के लिए है। @ऑपरेटर इस विवरण का स्तर (यह आदर्श वाक्य है नहीं है सब कुछ या कुछ ), और इसलिए प्रभावी त्रुटि प्रबंधन के लिए एक उपयुक्त उपकरण नहीं है।

ऐसे कुछ मामले हैं जहां आप जानते हैं कि एक निश्चित त्रुटि सामने आएगी , और यह कि वास्तविक समस्या को ठीक करना संदेश को शांत करने की तुलना में अधिक महंगा है (और इससे संभावित गिरावट का सामना करना पड़ता है)। यह एक-बंद स्क्रिप्ट में मामला हो सकता है, लेकिन अपनी उंगलियों को अपने कानों में चिपकाने और " ला ला ला " के लिए (संभावित) बग की व्यावसायिक प्रतिक्रिया नहीं है।

Comments

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

— जीरोने वेनवेल

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

@Paradoxical एक गंभीर साइट पर, आप "डेटाबेस त्रुटि" जैसे त्रुटि संदेश प्रदर्शित नहीं करेंगे और कुछ नहीं। आप बहुत सारे अतिरिक्त फ़ुल, स्टाइल, फ़ुटर इत्यादि के साथ एक सामान्य "आंतरिक सर्वर त्रुटि" पृष्ठ प्रदर्शित करेंगे, जो dieया तो उपयुक्त नहीं है। और विस्तृत जानकारी एक लॉग में जानी चाहिए, भले ही आप उपयोगकर्ता को दिखाए ।

क्या स्क्रीन पर उपयोगकर्ता के अनुकूल संदेश प्रस्तुत करने और लॉग फ़ाइल में तकनीकी संदेश लिखने का कोई तरीका नहीं है?

— FrustratedWithFormsDesigner

display_errorsबंद, log_errorsचालू, और आप जाने के लिए बहुत अच्छे हैं, जैसा कि आप एक त्रुटि का पता लगाने पर कृपया करते हैं, लेकिन उन्हें फेंक न दें।

— वरिकेन

Answer 3

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

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

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

Answer 4

हां, त्रुटि को दबाने वाला ऑपरेटर आमतौर पर एक बुरा विचार है।

आपको कॉन्फ़िगरेशन ( php.ini) में त्रुटि रिपोर्टिंग का प्रबंधन करना चाहिए । तो आप प्रत्येक वातावरण के लिए एक अलग सेटिंग चुन सकते हैं (उदाहरण के लिए, विकास में चेतावनी छोड़ें और उन्हें उत्पादन में छिपाएं)।

उपयोग करते समय एक ही स्थिति @समझ में आ सकती है जब आप अन्य डेवलपर्स के लिए एक पुस्तकालय विकसित करते हैं। यदि आप स्वेच्छा से ऐसा कुछ करना चुनते हैं जो चेतावनी पैदा करता है, और अपने पुस्तकालय के उपयोगकर्ताओं को चेतावनी के साथ नाराज नहीं करना चाहता जो उन पर निर्भर नहीं है, तो @समाधान हो सकता है।

मैं किसी अन्य उपयोग के बारे में नहीं सोच सकता।