क्या उपयोगकर्ता को प्रस्तुत त्रुटि संदेश में स्टैक ट्रेस होना चाहिए?

Question

मुझे अपने कार्यस्थल पर थोड़ा सा तर्क मिला है और मैं यह पता लगाने की कोशिश कर रहा हूं कि कौन सही है, और क्या करना सही है।

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

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

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

इसके अलावा, एक तत्काल और पूरी जानकारी होना विकास में बेहद उपयोगी है, जहाँ आपको हर अपवाद के लिए आवश्यक चीजों को खोजने के लिए लॉग फ़ाइलों के माध्यम से शिकार करने की आवश्यकता नहीं है। (लेकिन यह एक विन्यास स्विच के साथ हल किया जा सकता है।)

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

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

कौन सही है?

Comments

वाह। बस वाह। " Unfortunately there has been some kind of "Security audit"" - गंभीरता से? वह किस तरह का रवैया है? सुरक्षा ऑडिट आपके लाभ के लिए हैं - अपने सिस्टम को बेहतर बनाने के लिए, बुरे लोगों को करने से पहले समस्याओं का पता लगाने के लिए। आपको वास्तव में उनके साथ काम करने की कोशिश करने पर विचार करना चाहिए, उनके खिलाफ नहीं। इसके अलावा, आप सूचना सुरक्षा पर सुरक्षा PoV पर अधिक जानकारी प्राप्त करने का प्रयास कर सकते हैं ।

— अवीडी

और btw, एक सुरक्षा ऑडिट को स्रोत कोड तक पहुंच की आवश्यकता नहीं है, उन्होंने संभवतः एक ब्लैक-बॉक्स पैठ परीक्षण किया था, यह अनुकरण करते हुए कि एक दुर्भावनापूर्ण उपयोगकर्ता क्या करेगा - एक उपयोगकर्ता के रूप में एप्लिकेशन पर हमला करने की कोशिश करें। हालांकि मैं मानता हूं कि स्रोत कोड तक पहुंच ऑडिट के अधिक प्रभावी रूप को सक्षम कर सकती है। :-)

— AviD

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

— विल्क्स-

मैं तौल के बारे में बहुत सहमत हूं, लेकिन मैं इसके आवेदन से असहमत हूं। यह आपकी सोच से अधिक सुरक्षा को नुकसान पहुँचाता है, और मुझे यह भी लगता है कि आपका तरीका (खुद ऐसा किया है, भी, जब तक कि मैंने कुछ उपयोगकर्ताओं से बात नहीं की .....) प्रयोज्य के लिए बदतर है। इसे कार्य-उन्मुख शब्दों में सोचें - जैसा कि @ जॉन के जवाब में कहा गया है, उनका तरीका उपयोगकर्ता के काम को बेहतर तरीके से पूरा करता है। उपयोगकर्ता को स्टैक के बारे में परवाह करने की आवश्यकता नहीं है (जब तक कि आपके उपयोगकर्ता डेवलपर्स नहीं हैं ...) लेकिन, मेरी विशेषज्ञता सुरक्षा में है - और जोखिम वास्तविक हैं।

— शौकीन चावला

@ एवीडी - शायद आप मुझे कुछ संसाधनों की ओर इशारा कर सकते हैं जो बताते हैं कि स्टैक ट्रेस खतरनाक कैसे हो सकता है? मैं इसे स्वीकार करने के लिए तैयार हूं, लेकिन मुझे "केवल वही दिखाओ जो आपको चाहिए"।

— विल्क्स-

Answer 1

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

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

दूसरी चीज़ जिस पर आप विचार कर सकते हैं वह है सिस्टम की त्रुटियों का ईमेल विवरण जिसमें आपके पास मौजूद मेलबॉक्स है, इसलिए आपको पता है कि चीजें कब गलत हो रही हैं।

मौलिक रूप से एक प्रणाली है जो अपनी हिम्मत को तब बिखेरती है जब कुछ सही नहीं होता है जो गैर-तकनीकी उपयोगकर्ताओं में विश्वास को प्रेरित नहीं करता है - यह उन्हें सोचने में डराने की कोशिश करता है कि कुछ गलत है (जैसे कि बीएसओडी आपको कितना समझ में आता है, और कैसे करते हैं आपको लगता है कि जब कोई आता है)?

स्टैकट्रेस पर:

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

Comments

मुझे आपका उत्तर पसंद है क्योंकि यह एक "मध्य मार्ग" प्रस्तुत करता है - दिखावा नहीं है, लेकिन अपवादों की तलाश को आसान बनाते हैं। मैं अब उसके लिए जोर लगाने की कोशिश करूंगा, मुझे उम्मीद है कि वे सहमत होंगे। धन्यवाद!

— विल्क-

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

— डैनियल बी

@DanielB: वेब ऐप्स में सत्र / कैश से कुछ सामान्य सामान (जैसे यूजर, क्लायंट आदि) पकड़ना संभव है - क्योंकि यह "विश्व स्तर पर" कायम है, यहां तक ​​कि यह बहुत सी जानकारी त्रुटियों को पुन: उत्पन्न करने में मदद कर सकती है। जैसा कि आप कहते हैं उससे अधिक दानेदार बहुत मुश्किल है।

— जॉन एगर्टन

बहुत महत्वपूर्ण अनुप्रयोगों के कुछ उपयोगकर्ता किसी भी त्रुटि के तुरंत समाधान की मांग करते हैं जो व्यवसाय के सामान्य पाठ्यक्रम को बाधित करता है। त्रुटि-सॉल्वर के लिए बस विभिन्न डिसीप्लिन को शामिल करने वाली सभी संचार प्रक्रिया में त्रुटि स्टैक के लिए आसानी से 1 घंटे या उससे अधिक का उपभोग किया जा सकता है जब त्रुटि देर रात या सप्ताहांत पर होती है।

— ट्यूलेंस कोरडोवा

@ user1598390: सहमत, जिस स्थिति में मॉनिटर किए गए समर्थन मेलबॉक्स के लिए त्रुटि विवरण की प्रतिलिपि जानकारी के एकत्रीकरण को तेज कर सकती है, इस बात के लिए कि सहायक कर्मचारी कुछ जानता है, उपयोगकर्ता के भी पहले टूट गया है।

— जॉन एगर्टन

Answer 2

हां, कई हैं।

एक स्टैक ट्रेस प्रकट कर सकता है

• क्या एन्क्रिप्शन एल्गोरिथ्म आप का उपयोग करें
• आपके एप्लिकेशन सर्वर पर कुछ मौजूदा पथ क्या हैं
• आप इनपुट को ठीक से सैनिटाइज कर रहे हैं या नहीं
• आपकी वस्तुओं को आंतरिक रूप से कैसे संदर्भित किया जाता है
• डेटाबेस का कौन सा संस्करण और ब्रांड आपके फ्रंट-एंड के पीछे है

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

Comments

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

— ओलेक्सी

यह बात नहीं होनी चाहिए, लेकिन दुनिया अपूर्ण है, और अक्सर यह होता है। इसीलिए गहराई में रक्षा (कई चीजें एक साथ करना जो कि पूर्ण होने पर पर्याप्त होनी चाहिए ) मायने रखती हैं।

— किलन फ़ॉथ

स्पष्ट रूप से, यदि एक स्टैक ट्रेस से ऐसा कुछ भी पता चलता है जो हमलावर की मदद कर सकता है, तो आप इसे गलत कर रहे हैं !

— मार्क बूथ

@MarkBooth सांख्यिकीय बोल, आप शायद यह गलत कर रहे हैं। नहीं, खरोंच कि - सांख्यिकीय निश्चितता है कि आप इसे कुछ गलत कर रहे हैं। क्या आप वास्तव में हमलावरों को आपके सुरक्षा कीड़े ढूंढने देना चाहते हैं?

— AviD

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

— मार्क बूथ

Answer 3

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

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

क्यों न चिंता के दोनों स्रोतों को दरकिनार किया जाए और अपवाद रिपोर्टें स्वतः ही आपके पास भेजी जाएं? इस तरह आपको त्रुटियों की रिपोर्ट न करने वाले लोगों के बारे में चिंता करने की आवश्यकता नहीं है।

Comments

स्टैक ट्रेस द्वारा जानकारी के लिए धन्यवाद उसकी / उसकी समस्या के त्वरित निराकरण से उपयोगकर्ताओं को लाभ होता है। लेकिन मुझे आपकी बात समझ आ गयी है।

— ट्यूलेंस कोर्डोवा

Answer 4

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

आप वैसे भी उचित बैकएंड लॉगिंग से अधिकांश लाभ प्राप्त कर सकते हैं। यह थोड़ा कम दृढ़ है, लेकिन यह संभवतः आपके सिस्टम की गोपनीयता को खतरे में डालने और अपने ग्राहकों को परेशान करने के लायक नहीं है।

Answer 5

आप निम्नलिखित कारणों से स्टैक ट्रेस नहीं दिखाने पर विचार कर सकते हैं।

सुरक्षा

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

प्रयोगकर्ता का अनुभव

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

आपकी प्रतिष्ठा

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

Comments

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

— मटनज़

Answer 6

संक्षिप्त उत्तर: एक एक्स्ट्रानेट या इंटरनेट साइट में, यह समझ में नहीं आता है कि स्टैक्ट्रेस को नहीं दिखाना है। एक इंट्रानेट में स्टैकट्रेस दिखाने के फायदे इसे छिपाने वाले लोगों से अधिक हैं।

लंबा जवाब:

मेरे साथ भी ऐसा ही हुआ। मैं सोचता था कि यदि कोई ऐप विफल हो जाता है, तो इसे नीरवता से विफल होना चाहिए।

लेकिन तब उन्होंने मुझे समझाया कि एक पोटेंशियल हैकर ढेर सारी चीजों को ढेर कर सकता है।

मुझे लगता है कि सबूत की कोई जरूरत नहीं है। यह स्पष्ट है कि जितना अधिक एक हैकर आपके प्लेटफॉर्म के बारे में जानता है उतना ही उसके लिए बेहतर है और जितना कम हैकर आपके प्लेटफॉर्म के बारे में जानता है उतना ही आपके लिए बेहतर होगा ।

इसके अलावा कंपनियां यह बताने के लिए उत्सुक नहीं हैं कि एक हैकर उनके सिस्टम में कैसे फटा।

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

Comments

"अंतर्जात को जानने के क्या लाभ हैं जो गलत हो गए हैं", और वे एक लॉग फ़ाइल से पुनर्प्राप्त क्यों नहीं किए जा सकते हैं? ऐसा लगता है कि किसी इंट्रानेट के साथ, आप क्लाइंट साइट से लॉग फ़ाइल को और भी आसानी से एक्सेस कर सकते हैं।

— वोंको द साने

मेरे परिदृश्य में, महत्वपूर्ण अनुप्रयोग हैं जिनकी "7/24" प्राथमिकता है। उपयोगकर्ता कॉल हेल्प डेस्क, यदि समस्या एक अनुप्रयोग त्रुटि या अपवाद है, तो हेल्प डेस्क उस अनुचर को कॉल करता है जो शायद परिसर से दूर है। इस त्रुटि की जानकारी के बावजूद विशेषज्ञ किसी साइट पर काम करने वाले व्यक्ति को निर्देश दे सकता है ... यदि एप्लिकेशन व्यवसाय-महत्वपूर्ण है तो अक्सर सहेजा गया समय कीमती होता है। यदि विशेषज्ञ कि अगर प्रीमियर से पहले कंपनी से जुड़ना है, तो लॉग को खोजें, आदि, एक महत्वपूर्ण व्यावसायिक कार्य अनावश्यक रूप से इंतजार कर सकता है।

— ट्यूलेंस कोर्डोवा

@ user1598390 तो लॉग देखने के तंत्र का निर्माण करें। एक साधारण वेब पेज, घटना आईडी इनपुट, और हेल्पडेस्क पूरे प्रासंगिक लॉग देख सकते हैं। बेशक इस सुविधा तक पहुँच को सीमित करें, और इसके बाद ...

— AviD

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

— क्लिफ.meyers

Answer 7

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

दूसरी ओर, यदि घटनाओं की वास्तविक संख्या शून्य नहीं है, तो आपको इस जानकारी की सख्त आवश्यकता है, और आपको इसे भेजने के लिए ग्राहक पर भरोसा नहीं करना चाहिए। 99.99% समय वे नहीं करेंगे। आपको बग रिपेयरिंग सिस्टम स्थापित करना चाहिए जो ग्राहक को केवल "ओके" के साथ सूचना को स्वचालित रूप से प्रस्तुत करता है।

Comments

मैं निम्नलिखित पंक्ति के लिए अकेले इस उत्तर को बढ़ाऊंगा: "ग्राहक को इस जानकारी की उपयोगिता शून्य है।" । किसी उत्पाद के इंटर्नल के बारे में किसी भी तकनीकी विवरण को तब तक छिपाया जाना चाहिए जब तक कि उत्पाद के अंतिम उपयोगकर्ता के लिए सादगी और प्रयोज्य के सरल कारण के लिए ऐसा न करने का एक अच्छा कारण न हो।

— कजरतन