लाइब्रेरी के अंदर फेंकने और पकड़े गए अपवादों को अनदेखा करें

Question

पायथन मानक लाइब्रेरी और अन्य पुस्तकालय जो मैं उपयोग करता हूं (उदा। पीईक्यूटी) कभी-कभी गैर-त्रुटि स्थितियों के लिए अपवाद का उपयोग करता है। os.get_exec_path() फ़ंक्शन को छोड़कर निम्नलिखित को देखें। यह कुछ पर्यावरण डेटा खोजने की कोशिश करते समय फेंक दिए गए अपवादों को पकड़ने के लिए कई try कथन का उपयोग करता है।

try: 
    path_list = env.get('PATH') 
except TypeError: 
    path_list = None 

if supports_bytes_environ: 
    try: 
     path_listb = env[b'PATH'] 
    except (KeyError, TypeError): 
     pass 
    else: 
     if path_list is not None: 
      raise ValueError(
       "env cannot contain 'PATH' and b'PATH' keys") 
     path_list = path_listb 

    if path_list is not None and isinstance(path_list, bytes): 
     path_list = fsdecode(path_list) 

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

क्या PyCharm में या पाइथन में सामान्य रूप से डीबगर को अपवादों पर तोड़ने और मेरे कोड की किसी भी भागीदारी के बिना लाइब्रेरी के अंदर पकड़े गए अपवादों को तोड़ने का कोई तरीका नहीं है?

Answer 1

यह सुविधा अभी तक लागू नहीं किया गया है, तो आप इसके लिए मतदान कर सकते हैं:

• add ability to break (add breakpoint) on exceptions only for my files

Answer 2

नहीं है एक और तो एक समाधान के साथ जवाब दें: Debugging with pycharm, how to step into project, without entering django libraries

यह मेरे लिए काम कर रहा है , सिवाय इसके कि मैं अभी भी "_pydev_execfile.py" फ़ाइल में जाता हूं, लेकिन मैंने लिंक किए गए उत्तर में बहिष्करण में जोड़ने के बाद अन्य फ़ाइलों में कदम नहीं उठाया है।

Answer 3

पायचर्म में, रन -> देखें ब्रेकपॉइंट्स पर जाएं, और "raise पर जाएं" और "लाइब्रेरी फ़ाइलों को अनदेखा करें"।

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

समाधान को अनुरोध के बाद CrazyCoder के link के लिए धन्यवाद मिला, जिसे बाद में जोड़ा गया है।

Answer 4

थोड़ी देर के लिए मैं एक जटिल योजना है जिसमें निम्नलिखित की तरह कुछ शामिल था:

try(Closeable ignore = Debugger.newBreakSuppression()) 
{ 
    ... library call which may throw ... 
} <-- exception looks like it is thrown here 

यह अनुमति मुझे अपवाद फेंक दिया और पुस्तकालय कॉल के अंतर्गत निगल लिया द्वारा कभी नहीं परेशान होना। यदि लाइब्रेरी कॉल द्वारा अपवाद फेंक दिया गया था और पकड़ा नहीं गया था, तो ऐसा प्रतीत होता है जैसे यह समापन घुंघराले ब्रैकेट पर हुआ था।

Closeable एक अंतरफलक जो किसी भी अपवाद जाँच की घोषणा के बिना AutoCloseable फैली हुई है:

जिस तरह से यह काम किया इस प्रकार थी।

ignore सिर्फ एक ऐसा नाम है जो इंटेलिजे आईडीईए को अप्रयुक्त चर के बारे में शिकायत नहीं करने के लिए कहता है, और यह आवश्यक है क्योंकि मूर्ख जावा try(Debugger.newBreakSuppression()) का समर्थन नहीं करता है।

Debugger डीबगिंग से संबंधित सहायक विधियों के साथ मेरी अपनी कक्षा है।

newBreakSuppression() एक ऐसी विधि थी जो BreakSuppression कक्षा का थ्रेड-स्थानीय उदाहरण तैयार करेगी जो इस तथ्य को ध्यान में रखेगी कि हम अस्थायी रूप से निलंबित होने के लिए ब्रेक-ऑन-अपवाद चाहते हैं।

तो मैं एक ब्रेक शर्त यह है कि मेरी Debugger वर्ग आह्वान पूछने के लिए कि क्या इसे तोड़ने के लिए ठीक है जाएगा के साथ एक अपवाद ब्रेकप्वाइंट था, और Debugger वर्ग के साथ एक "नहीं" यदि कोई BreakSuppression वस्तुओं instantiated गया जवाब देगा।

यह बेहद जटिल था, क्योंकि वीएम मेरे कोड लोड होने से पहले अपवाद फेंकता है, इसलिए फ़िल्टर स्टार्टअप के दौरान फ़िल्टर का मूल्यांकन नहीं किया जा सकता था, और डीबगर इस बात को अनदेखा करने के बजाय इसके बारे में शिकायत करने वाले संवाद को पॉप अप करेगा। (मैं इसके बारे में शिकायत नहीं कर रहा हूं, मुझे चुप त्रुटियों से नफरत है।) इसलिए, मुझे एक भयानक, भयानक, कोशिश-पर-कोशिश-घर पर हैक करना था जहां ब्रेक की स्थिति इस तरह दिखेगी: java.lang.System.err.equals(this) आम तौर पर, यह कभी भी वापस नहीं आएगा, क्योंकि System.err किसी फेंकने वाले अपवाद के बराबर नहीं है, इसलिए डीबगर कभी नहीं टूट जाएगा। हालांकि, जब मेरी Debugger कक्षा शुरू हो जाएगी, तो System.err को अपनी खुद की कक्षा, से प्रतिस्थापित कर दिया जाएगा, जिसने equals(Object) के लिए कार्यान्वयन प्रदान किया और डीबगर को तोड़ने पर true लौटा दिया। इसलिए, अनिवार्य रूप से, मैं एक अनंत वैश्विक चर के रूप में System.err का उपयोग कर रहा था।

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