efamilant
asked on
java program fails when instantiating a class but no stack trace or other information present on console
A java program I've written is failing when a class is instantiated in some environments. I suspect it is a memory problem but would like to confirm this with some kind of stack trace. I've tried putting a try catch block around the statement where the class is instantiated but I still see nothing (the module just stops running). Is there some way I can force some error message or stack trace in this situation? This is running in a windows environment. When run from the command line, it just returns to the command line. There is no other information. There is nothing in system.out after the statement that tries to instantiate the class.
ASKER
Several reasons:
1. The program does not produce the expected output
2. Debugging statements that follow the class instantiation do not appear in the console
3. log4j logging ceases right before the statement causing the problem.
1. The program does not produce the expected output
2. Debugging statements that follow the class instantiation do not appear in the console
3. log4j logging ceases right before the statement causing the problem.
I would say that without the code it's unlikely anyone can really help much.
You say that it fails when running in certain environments, then say that it is under Windows. This apparent contradiction, and no code, is not going to attract many comments - apart from ones like this.
You say that it fails when running in certain environments, then say that it is under Windows. This apparent contradiction, and no code, is not going to attract many comments - apart from ones like this.
krakatoa is right -- it's hard to help when you don't post any code or error messages.
However -- to print a stack trace from a running java program in a terminal window in Windows, you do this:
<ctrl><break>
However -- to print a stack trace from a running java program in a terminal window in Windows, you do this:
<ctrl><break>
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
. . . which is why I said this :
then how do you know it has not run and executed?
efamilant: should you ask another question where you want help, it is much more successful to respond to the experts who are trying to help you. Without feedback, it's very hard for us to guess what you are seeing.
As stated, an inspection of the code would have been a waste of timeAs stated? Where did you state this?
I guess, that in some situations, it results in the jre simply existing the program prematurely without any error messages or stack tracesNo, unless you have stumbled across some fairly hidden bug in the JRE then I highly doubt this. A much more likely situation is that either some part of yor code, or some third party library that you are using, is what is responsible for exiting with no feedback, or is swallowing any feedback that may have been provided. Personally, that is something that I would look into more deeply if I were in the same situation, because it may rear itself again at a later time in a different place, and this would make debugging quite difficult. This is where providing the code (or at least some of the code) could of allowed us to provide more help, and possibly pinpointed the actual problem.
ASKER
It is the answer
Bad.
ASKER
I respectfully disagree. Code inspection would not have helped in this case. Here is why. When Java instantiates a class, it finds all the jars that are needed to create that class and uses them during the instantiation. What I learned from this problem is that if some of those jars are not present, then the entire program can simply abend. How could you have known this by simple code inspection? All you would have seen was the instantiation of a class:
Myclass myclass = new Myclass(paramenter1, parameter2);
This tells you nothing. The class itself uses jars which when present in the running environment allows the class to be instantiated. It is a fallacy, I believe, that every programming problem can be addressed by code inspection. Some of the most pernicious problems I've encountered recently are environment issues. Issues related to the computer environment outside the code module itself (missing jar issues or memory issues). That is my point.
Myclass myclass = new Myclass(paramenter1, parameter2);
This tells you nothing. The class itself uses jars which when present in the running environment allows the class to be instantiated. It is a fallacy, I believe, that every programming problem can be addressed by code inspection. Some of the most pernicious problems I've encountered recently are environment issues. Issues related to the computer environment outside the code module itself (missing jar issues or memory issues). That is my point.
Well, I suppose some possibility like that might exist; but mccarl especially is unlikely to have made the comment he did just in passing as they say. Only his return will tell if he is convinced of your argument. I can't say I am convinced, since any programme consists of references, and if those references are broken, then you would or should be able to see that from inspecting the code.
ASKER
Here is how it happens. The jar is built in an ide like Eclipse where the path in the development environment points to a set of jars that are used by the module. Then only some of the jars make it to some other environment (say a production environment). In the ide there are no hanging references because the missing jars are present in the development environment. But are missing in the other environment, causing the error at runtime. What I learned was putting a run time try catch clause around the code that instantiates the class, does not result in java throwing an error (at least in this case). Instead, the module simply stops working at the point where the class is instantiated.
You're right except for the "just stop working" part. What happens is that the java process throws an exception. However, it is from the classloader, which is why a try/catch around the attempt to create a new object will not catch the exception.
If you had worked with us on this, we would have started pointing you to the logs from the process -- at the very least, the stderr log from your process. You would have seen the classnotfound (or whatever it was ) exception there.
If you had worked with us on this, we would have started pointing you to the logs from the process -- at the very least, the stderr log from your process. You would have seen the classnotfound (or whatever it was ) exception there.
ASKER
I was running this from the console. You are saying that stderr does not throw its messages to the console but somewhere else?
ClassNotFound and other classloader exceptions are thrown and jetty should not be hiding them. So I assume jetty puts them somewhere. Maybe not -- check your jetty configuration.
Sorry -- you're not the one using jetty. The console should have shown the errors.
However, lots of things can redirect output. Are you using log4j for your logging? It's possible that exceptions are being captured and written to a log rather than showing in the console.
However, lots of things can redirect output. Are you using log4j for your logging? It's possible that exceptions are being captured and written to a log rather than showing in the console.
ASKER
I am using log4j but the errors did not appear there, unfortunately.
Right -- your log4j properties file would have had to redirect stderr somewhere else in order for them not to come to the console. If you looked in all your log4j files and didn't find the exception, then probably that didn't happen.
It's hard to debug this remotely, but the main facts are that exceptions are thrown, and unless something odd is done, they are displayed back to the user. This happens even if (especially if) it's a runtime-only exception, as it seems yours was.
If the classnotfound (or whatever the classloader exception) exception is in a 3rd party jar, then possibly the log from that jar is being swallowed somewhere. Bad application design, but people often don't think about errors which can happen in the multitude of user execution environments.
It's hard to debug this remotely, but the main facts are that exceptions are thrown, and unless something odd is done, they are displayed back to the user. This happens even if (especially if) it's a runtime-only exception, as it seems yours was.
If the classnotfound (or whatever the classloader exception) exception is in a 3rd party jar, then possibly the log from that jar is being swallowed somewhere. Bad application design, but people often don't think about errors which can happen in the multitude of user execution environments.
There is no other information.
No. Not for you, nor for us. Not even the information that you are not relying solely on Java for debugging, but for something else like log4j.
I didn't sign up to EE as a clairvoyant.
If there are no exceptions or runtime errors as you say, then how do you know it has not run and executed?