स्टैक ट्रेस क्या है, और मैं इसका उपयोग अपनी एप्लिकेशन त्रुटियों को डीबग करने के लिए कैसे कर सकता हूं?
कभी-कभी जब मैं अपना आवेदन चलाता हूं तो यह मुझे एक त्रुटि देता है जो दिखता है:
Exception in thread "main" java.lang.NullPointerException
at com.example.myproject.Book.getTitle(Book.java:16)
at com.example.myproject.Author.getBookTitles(Author.java:25)
at com.example.myproject.Bootstrap.main(Bootstrap.java:14)
लोगों ने इसे "स्टैक ट्रेस" के रूप में संदर्भित किया है। स्टैक ट्रेस क्या है? यह मेरे कार्यक्रम में होने वाली त्रुटि के बारे में मुझे क्या बता सकता है?
इस सवाल के बारे में - काफी बार मुझे एक सवाल आता है कि एक नौसिखिया प्रोग्रामर "त्रुटि प्राप्त कर रहा है", और वे बस अपने स्टैक ट्रेस और कोड के कुछ यादृच्छिक ब्लॉक को यह समझने के बिना पेस्ट करते हैं कि स्टैक ट्रेस क्या है या वे इसका उपयोग कैसे कर सकते हैं। यह सवाल नौसिखिए प्रोग्रामर के लिए एक संदर्भ के रूप में है, जिन्हें स्टैक ट्रेस के मूल्य को समझने में मदद की आवश्यकता हो सकती है।
जवाब
सरल शब्दों में, एक स्टैक ट्रेस विधि कॉल की एक सूची है जो अनुप्रयोग के बीच में था जब एक अपवाद को फेंक दिया गया था।
सरल उदाहरण
प्रश्न में दिए गए उदाहरण के साथ, हम यह निर्धारित कर सकते हैं कि आवेदन में अपवाद को कहां फेंक दिया गया था। आइए स्टैक ट्रेस पर एक नज़र डालें:
Exception in thread "main" java.lang.NullPointerException
at com.example.myproject.Book.getTitle(Book.java:16)
at com.example.myproject.Author.getBookTitles(Author.java:25)
at com.example.myproject.Bootstrap.main(Bootstrap.java:14)
यह एक बहुत ही सरल स्टैक ट्रेस है। यदि हम "एट ..." की सूची की शुरुआत में शुरू करते हैं, तो हम बता सकते हैं कि हमारी गलती कहां हुई। हम जिस चीज की तलाश कर रहे हैं वह सबसे ऊपरी विधि कॉल है जो हमारे एप्लिकेशन का हिस्सा है। इस मामले में, यह है:
at com.example.myproject.Book.getTitle(Book.java:16)
इसे डीबग करने के लिए, हम खोल सकते हैं Book.javaऔर लाइन को देख सकते हैं 16, जो है:
15 public String getTitle() {
16 System.out.println(title.toString());
17 return title;
18 }
यह इंगित करेगा कि उपरोक्त कोड में कुछ (शायद title) है null।
अपवादों की श्रृंखला के साथ उदाहरण
कभी-कभी एप्लिकेशन एक अपवाद को पकड़ लेंगे और इसे दूसरे अपवाद के कारण के रूप में फिर से फेंक देंगे। यह आमतौर पर ऐसा दिखता है:
34 public void getBookIds(int id) {
35 try {
36 book.getId(id); // this method it throws a NullPointerException on line 22
37 } catch (NullPointerException e) {
38 throw new IllegalStateException("A book has a null property", e)
39 }
40 }
यह आपको एक स्टैक ट्रेस दे सकता है जो दिखता है:
Exception in thread "main" java.lang.IllegalStateException: A book has a null property
at com.example.myproject.Author.getBookIds(Author.java:38)
at com.example.myproject.Bootstrap.main(Bootstrap.java:14)
Caused by: java.lang.NullPointerException
at com.example.myproject.Book.getId(Book.java:22)
at com.example.myproject.Author.getBookIds(Author.java:36)
... 1 more
इस एक के बारे में क्या अलग है "इसके कारण"। कभी-कभी अपवादों में कई "कारण" खंड होंगे। इनके लिए, आप आम तौर पर "मूल कारण" को ढूंढना चाहते हैं, जो स्टैक ट्रेस में "वर्गों द्वारा सबसे कम" कारणों में से एक होगा। हमारे मामले में, यह है:
Caused by: java.lang.NullPointerException <-- root cause
at com.example.myproject.Book.getId(Book.java:22) <-- important line
फिर, यह अपवाद के साथ हम लाइन को देखने के लिए चाहते हैं 22की Book.javaक्या कारण हो सकता है देखने के लिए NullPointerExceptionयहाँ।
लाइब्रेरी कोड के साथ अधिक चुनौतीपूर्ण उदाहरण
आमतौर पर स्टैक के निशान ऊपर के दो उदाहरणों की तुलना में बहुत अधिक जटिल होते हैं। यहाँ एक उदाहरण है (यह एक लंबा है, लेकिन जंजीर अपवादों के कई स्तरों को प्रदर्शित करता है):
javax.servlet.ServletException: Something bad happened
at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:60)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at com.example.myproject.ExceptionHandlerFilter.doFilter(ExceptionHandlerFilter.java:28) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.example.myproject.OutputBufferFilter.doFilter(OutputBufferFilter.java:33)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Caused by: com.example.myproject.MyProjectServletException
at com.example.myproject.MyServlet.doPost(MyServlet.java:169)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:30) ... 27 more Caused by: org.hibernate.exception.ConstraintViolationException: could not insert: [com.example.myproject.MyEntity] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:96) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.id.insert.AbstractSelectingDelegate.performInsert(AbstractSelectingDelegate.java:64) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2329) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2822) at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:71) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:268) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:321) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:130) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:210) at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:56) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:195) at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:50) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:93) at org.hibernate.impl.SessionImpl.fireSave(SessionImpl.java:705) at org.hibernate.impl.SessionImpl.save(SessionImpl.java:693) at org.hibernate.impl.SessionImpl.save(SessionImpl.java:689) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:344)
at $Proxy19.save(Unknown Source)
at com.example.myproject.MyEntityService.save(MyEntityService.java:59) <-- relevant call (see notes below)
at com.example.myproject.MyServlet.doPost(MyServlet.java:164)
... 32 more
Caused by: java.sql.SQLException: Violation of unique constraint MY_ENTITY_UK_1: duplicate value(s) for column(s) MY_COLUMN in statement [...]
at org.hsqldb.jdbc.Util.throwError(Unknown Source)
at org.hsqldb.jdbc.jdbcPreparedStatement.executeUpdate(Unknown Source)
at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeUpdate(NewProxyPreparedStatement.java:105)
at org.hibernate.id.insert.AbstractSelectingDelegate.performInsert(AbstractSelectingDelegate.java:57)
... 54 more
इस उदाहरण में, बहुत अधिक है। हम जिस चीज के बारे में ज्यादातर चिंतित हैं, वह हमारे कोड के तरीकों की तलाश में है , जो com.example.myprojectपैकेज में कुछ भी होगा । दूसरे उदाहरण (ऊपर) से, हम पहले मूल कारण के लिए नीचे देखना चाहते हैं, जो है:
Caused by: java.sql.SQLException
हालाँकि, इसके तहत सभी विधि कॉल लाइब्रेरी कोड हैं। तो हम इसे ऊपर "कारण" तक ले जाएंगे, और हमारे कोड से उत्पन्न होने वाली पहली विधि कॉल की तलाश करेंगे, जो है:
at com.example.myproject.MyEntityService.save(MyEntityService.java:59)
पिछले उदाहरणों की तरह, हमें MyEntityService.javaलाइन पर देखना चाहिए 59, क्योंकि यह त्रुटि उत्पन्न हुई है (यह थोड़ा स्पष्ट है कि गलत क्या हुआ, क्योंकि SQLException त्रुटि बताता है, लेकिन डिबगिंग प्रक्रिया वह है जो हम बाद में करते हैं)।
मैं इस जवाब को पोस्ट कर रहा हूं इसलिए सबसे ऊपरी उत्तर (जब गतिविधि द्वारा क्रमबद्ध किया गया) एक ऐसा नहीं है जो सिर्फ सादा गलत है।
स्टैकट्रेस क्या है?
स्टैकट्रेस एक बहुत ही उपयोगी डिबगिंग टूल है। यह कॉल स्टैक को दिखाता है (मतलब, फ़ंक्शन का स्टैक जिसे उस बिंदु तक कहा जाता था) उस समय एक अनकहा अपवाद को फेंक दिया गया था (या समय स्टैकट्रेस मैन्युअल रूप से उत्पन्न हुआ था)। यह बहुत उपयोगी है क्योंकि यह न केवल आपको दिखाता है कि त्रुटि कहां हुई, बल्कि यह भी कि कोड के उस स्थान पर प्रोग्राम कैसे समाप्त हुआ। यह अगले प्रश्न की ओर जाता है:
एक अपवाद क्या है?
एक अपवाद वह है जो रनटाइम वातावरण आपको यह बताने के लिए उपयोग करता है कि कोई त्रुटि हुई। लोकप्रिय उदाहरण NullPointerException, IndexOutOfBoundsException या ArithmeticException हैं। इनमें से प्रत्येक तब होता है जब आप कुछ ऐसा करने की कोशिश करते हैं जो संभव नहीं है। उदाहरण के लिए, NullPointerException को तब फेंका जाएगा जब आप किसी नल-ऑब्जेक्ट को डीरेल करने की कोशिश करेंगे:
Object a = null;
a.toString(); //this line throws a NullPointerException
Object[] b = new Object[5];
System.out.println(b[10]); //this line throws an IndexOutOfBoundsException,
//because b is only 5 elements long
int ia = 5;
int ib = 0;
ia = ia/ib; //this line throws an ArithmeticException with the
//message "/ by 0", because you are trying to
//divide by 0, which is not possible.
स्टैकट्रैक्स / अपवाद के साथ मुझे कैसे व्यवहार करना चाहिए?
सबसे पहले, पता करें कि अपवाद क्या है। अपवाद का नाम जानने के लिए Google का प्रयास करें, उस अपवाद का कारण क्या है। अधिकांश समय यह गलत कोड के कारण होगा। ऊपर दिए गए उदाहरणों में, सभी अपवाद गलत कोड के कारण हैं। तो NullPointerException उदाहरण के लिए आप यह सुनिश्चित कर सकते हैं कि aउस समय कभी भी अशक्त नहीं है। उदाहरण के लिए, आप aइस तरह की जाँच या आरंभ कर सकते हैं:
if (a!=null) {
a.toString();
}
इस तरह, यदि आपत्तिजनक लाइन निष्पादित नहीं की जाती है a==null। वही अन्य उदाहरणों के लिए जाता है।
कभी-कभी आप यह सुनिश्चित नहीं कर सकते हैं कि आपको अपवाद नहीं मिलता है। उदाहरण के लिए, यदि आप अपने प्रोग्राम में नेटवर्क कनेक्शन का उपयोग कर रहे हैं, तो आप कंप्यूटर को इंटरनेट कनेक्शन खोने से रोक नहीं सकते हैं (जैसे कि आप उपयोगकर्ता को कंप्यूटर के नेटवर्क कनेक्शन को डिस्कनेक्ट करने से नहीं रोक सकते)। इस मामले में नेटवर्क लाइब्रेरी शायद एक अपवाद फेंक देगी। अब आपको अपवाद को पकड़ना चाहिए और इसे संभालना चाहिए। इसका अर्थ है, नेटवर्क कनेक्शन के साथ उदाहरण में, आपको कनेक्शन को फिर से खोलने या उपयोगकर्ता या उस जैसे कुछ को सूचित करने का प्रयास करना चाहिए। इसके अलावा, जब भी आप कैच का उपयोग करते हैं, तो हमेशा केवल उस अपवाद को पकड़ें जिसे आप पकड़ना चाहते हैं, ऐसे व्यापक कैच कथनों का उपयोग न करें,catch (Exception e) जो सभी अपवादों को पकड़ेंगे। यह बहुत महत्वपूर्ण है, क्योंकि अन्यथा आप गलती से गलत अपवाद को पकड़ सकते हैं और गलत तरीके से प्रतिक्रिया कर सकते हैं।
try {
Socket x = new Socket("1.1.1.1", 6789);
x.getInputStream().read()
} catch (IOException e) {
System.err.println("Connection could not be established, please try again later!")
}
मुझे क्यों नहीं उपयोग करना चाहिए catch (Exception e)?
चलो यह दिखाने के लिए एक छोटे से उदाहरण का उपयोग करें कि आपको सभी अपवादों को क्यों नहीं पकड़ना चाहिए:
int mult(Integer a,Integer b) {
try {
int result = a/b
return result;
} catch (Exception e) {
System.err.println("Error: Division by zero!");
return 0;
}
}
यह कोड जो करने की कोशिश कर रहा है, वह ArithmeticExceptionसंभावित विभाजन के कारण 0. को पकड़ने के लिए है। लेकिन यह भी संभव है NullPointerExceptionकि अगर aया bहो तो फेंक दिया जाता है null। इसका मतलब है, आपको मिल सकता है NullPointerExceptionलेकिन आप इसे एक अंकगणित के रूप में मानेंगे और शायद गलत काम करेंगे। सबसे अच्छे मामले में आप अभी भी याद करते हैं कि एक NullPointerException थी। सामान की तरह यह बहुत कठिन डिबगिंग बनाता है, तो ऐसा मत करो।
TLDR
- यह पता लगाएं कि अपवाद का कारण क्या है और इसे ठीक करें, ताकि यह अपवाद बिल्कुल न फेंके।
यदि 1. संभव नहीं है, तो विशिष्ट अपवाद को पकड़ें और इसे संभाल लें।
- कभी भी बस एक कोशिश / पकड़ जोड़ें और फिर अपवाद को अनदेखा करें! ऐसा मत करो!
- कभी भी उपयोग न करें
catch (Exception e), हमेशा विशिष्ट अपवादों को पकड़ें। जो आपको बहुत सारे सिरदर्द से बचाएगा।
रोब का उल्लेख किया है पर जोड़ने के लिए। अपने आवेदन में ब्रेक पॉइंट सेट करना स्टैक के चरण-दर-चरण प्रसंस्करण के लिए अनुमति देता है। यह डेवलपर को डिबगर का उपयोग करने के लिए सक्षम करता है यह देखने के लिए कि सटीक तरीका कुछ ऐसा कर रहा है जो अप्रत्याशित था।
चूँकि रोब ने NullPointerExceptionNPE (NPE) का उपयोग कुछ सामान्य करने के लिए किया है, हम इस समस्या को निम्नलिखित तरीके से दूर करने में मदद कर सकते हैं:
अगर हमारे पास एक तरीका है जो पैरामीटर लेता है जैसे: void (String firstName)
हमारे कोड में हम मूल्यांकन करना चाहते हैं firstNameजिसमें एक मान शामिल है, हम ऐसा करेंगे:if(firstName == null || firstName.equals("")) return;
उपरोक्त हमें firstNameअसुरक्षित पैरामीटर के रूप में उपयोग करने से रोकता है । इसलिए प्रसंस्करण से पहले अशक्त जांच करने से हम यह सुनिश्चित करने में मदद कर सकते हैं कि हमारा कोड ठीक से चलेगा। एक उदाहरण का विस्तार करने के लिए जो किसी ऐसी वस्तु का उपयोग करता है जिसमें हम यहां देख सकते हैं:
if(dog == null || dog.firstName == null) return;
उपर्युक्त नलियों की जांच करने का उचित आदेश है, हम इस मामले में आधार वस्तु, कुत्ते से शुरू करते हैं, और फिर प्रसंस्करण के पहले सब कुछ मान्य है यह सुनिश्चित करने के लिए संभावनाओं के पेड़ के नीचे चलना शुरू करते हैं। यदि आदेश उलटा होता तो एनपीई संभावित रूप से फेंका जा सकता था और हमारा कार्यक्रम दुर्घटनाग्रस्त हो जाता।
थ्रेडेबल परिवार द्वारा पेश की जाने वाली एक और स्टैकट्रेस सुविधा है - स्टैक ट्रेस जानकारी में हेरफेर करने की संभावना ।
मानक व्यवहार:
package test.stack.trace;
public class SomeClass {
public void methodA() {
methodB();
}
public void methodB() {
methodC();
}
public void methodC() {
throw new RuntimeException();
}
public static void main(String[] args) {
new SomeClass().methodA();
}
}
स्टैक ट्रेस:
Exception in thread "main" java.lang.RuntimeException
at test.stack.trace.SomeClass.methodC(SomeClass.java:18)
at test.stack.trace.SomeClass.methodB(SomeClass.java:13)
at test.stack.trace.SomeClass.methodA(SomeClass.java:9)
at test.stack.trace.SomeClass.main(SomeClass.java:27)
मैनिप्युलेटेड स्टैक ट्रेस:
package test.stack.trace;
public class SomeClass {
...
public void methodC() {
RuntimeException e = new RuntimeException();
e.setStackTrace(new StackTraceElement[]{
new StackTraceElement("OtherClass", "methodX", "String.java", 99),
new StackTraceElement("OtherClass", "methodY", "String.java", 55)
});
throw e;
}
public static void main(String[] args) {
new SomeClass().methodA();
}
}
स्टैक ट्रेस:
Exception in thread "main" java.lang.RuntimeException
at OtherClass.methodX(String.java:99)
at OtherClass.methodY(String.java:55)
नाम समझने के लिए : एक स्टैक ट्रेस अपवाद की एक सूची है (या आप "कारण द्वारा" की एक सूची कह सकते हैं), सबसे सतह अपवाद (जैसे सेवा परत अपवाद) से सबसे गहरी एक (उदाहरण के लिए डेटाबेस अपवाद)। जिस तरह से हम इसे 'स्टैक' कहते हैं, क्योंकि स्टैक फर्स्ट इन लास्ट आउट (FILO) है, सबसे गहरा अपवाद बहुत शुरुआत में हुआ था, तब अपवाद की एक श्रृंखला कई परिणाम उत्पन्न करती थी, सतह अपवाद अंतिम था एक समय में हुआ, लेकिन हम इसे पहली जगह में देखते हैं।
कुंजी 1 : यहां एक मुश्किल और महत्वपूर्ण बात समझने की जरूरत है: सबसे गहरा कारण "मूल कारण" नहीं हो सकता है, क्योंकि यदि आप कुछ "बुरा कोड" लिखते हैं, तो यह कुछ अपवाद का कारण हो सकता है जो इसकी परत से गहरा है। उदाहरण के लिए, एक खराब एसक्यूएल क्वेरी सिंडीक्स त्रुटि के बजाय बोटेम में SQLServerException कनेक्शन रीसेट का कारण हो सकती है, जो कि स्टैक के बीच में हो सकती है।
-> बीच में मूल कारण का पता लगाना आपका काम है।
कुंजी 2 : एक और मुश्किल लेकिन महत्वपूर्ण बात यह है कि प्रत्येक "कॉज बाय" ब्लॉक के अंदर है, पहली पंक्ति सबसे गहरी परत थी और इस ब्लॉक में पहले स्थान पर थी। उदाहरण के लिए,
Exception in thread "main" java.lang.NullPointerException
at com.example.myproject.Book.getTitle(Book.java:16)
at com.example.myproject.Author.getBookTitles(Author.java:25)
at com.example.myproject.Bootstrap.main(Bootstrap.java:14)
Book.java:16 को Auther.java:25 द्वारा कॉल किया गया था जिसे Bootstrap.java:14, Book.java:16 ने मूल कारण बताया था। यहाँ कालानुक्रम क्रम में ट्रेस स्टैक की तरह एक आरेख संलग्न करें।
बस अन्य उदाहरणों में जोड़ने के लिए, आंतरिक (नेस्टेड) वर्ग हैं जो $संकेत के साथ दिखाई देते हैं । उदाहरण के लिए:
public class Test {
private static void privateMethod() {
throw new RuntimeException();
}
public static void main(String[] args) throws Exception {
Runnable runnable = new Runnable() {
@Override public void run() {
privateMethod();
}
};
runnable.run();
}
}
इस स्टैक ट्रेस में परिणाम होगा:
Exception in thread "main" java.lang.RuntimeException
at Test.privateMethod(Test.java:4)
at Test.access$000(Test.java:1)
at Test$1.run(Test.java:10)
at Test.main(Test.java:13)
अन्य पोस्ट बताते हैं कि स्टैक ट्रेस क्या है, लेकिन इसके साथ काम करना मुश्किल हो सकता है।
यदि आपको स्टैक ट्रेस मिलता है और अपवाद के कारण का पता लगाना चाहते हैं, तो यह समझने में एक अच्छी शुरुआत है कि ग्रहण में जावा स्टैक ट्रेस कंसोल का उपयोग करना है । यदि आप किसी अन्य आईडीई का उपयोग करते हैं तो एक समान सुविधा हो सकती है, लेकिन यह उत्तर ग्रहण के बारे में है।
सबसे पहले, सुनिश्चित करें कि आप अपने सभी जावा स्रोतों को एक ग्रहण परियोजना में सुलभ हैं।
फिर जावा परिप्रेक्ष्य में, कंसोल टैब (आमतौर पर तल पर) पर क्लिक करें । यदि कंसोल दृश्य दिखाई नहीं देता है, तो मेनू विकल्प विंडो पर जाएं -> दृश्य देखें और कंसोल चुनें ।
फिर कंसोल विंडो में, निम्न बटन पर क्लिक करें (दाईं ओर)
और फिर ड्रॉप-डाउन सूची से जावा स्टैक ट्रेस कंसोल का चयन करें ।
कंसोल में अपने स्टैक ट्रेस चिपकाएँ। यह तब आपके स्रोत कोड और किसी भी अन्य स्रोत कोड में लिंक की एक सूची प्रदान करेगा।
यह वही है जो आप देख सकते हैं (ग्रहण प्रलेखन से छवि):
सबसे हालिया मेथड कॉल कॉल स्टैक के शीर्ष पर होगी , जो शीर्ष पंक्ति (संदेश पाठ को छोड़कर) है। स्टैक के नीचे जाने से समय में वापस चला जाता है। दूसरी पंक्ति वह विधि है जो पहली पंक्ति को कॉल करती है, आदि।
यदि आप ओपन-सोर्स सॉफ़्टवेयर का उपयोग कर रहे हैं, तो आपको अपनी परियोजना के स्रोतों को डाउनलोड करने और संलग्न करने की आवश्यकता हो सकती है यदि आप जांच करना चाहते हैं। स्रोत जार डाउनलोड करें, अपनी परियोजना में, अपने ओपन-सोर्स मॉड्यूल (वर्ग फ़ाइलों के साथ एक) के लिए अपना जार खोजने के लिए संदर्भित लाइब्रेरी फ़ोल्डर खोलें, फिर राइट क्लिक करें, गुण चुनें और स्रोत जार संलग्न करें।