If I have written a program in Java, how can I know if my program has terminated normally or exited normally?
I'm guessing a little here, since your question is kinda vague. But I assume you talk about finding out within your program that this program terminated normally or not when it was last run.
If you got something of a configuration directory or file—leave a note there, when the program starts and remove said note when your process exits normally. If that note is still there when your program starts then either another instance is still running (something you'd need to check separately then) or it didn't terminate normally.
The JVM returns an integer exit code upon termination of your program, with 0 meaning the program terminated correctly, and a non-zero value usually representing an error condition.
If your program comes to an end normally (i.e. the main method returns without throwing an exception), then the JVM will return 0, otherwise, if an exception is thrown and not caught, then the JVM will return a non-zero error code.
You can also set the error code yourself, via the System.exit(int) method. This causes the JVM to immediately terminate and return the specified error code.
Assuming you're on a Windows based machine, you can then see the error code returned by echoing the %ERRORLEVEL% property.
For example assuming you have a class Main, you can see the error code like this:
C:\>java Main
C:\>echo %ERRORLEVEL%
0
If you then changed main to call System.exit(1), then the error level would look like this:
C:\>echo %ERRORLEVEL%
1
Related
If I kill an Android app with System.exit(...), does it matter what status code I pass? I couldn't find any documentation on whether Android just ignores it or whether certain ones lead to any error messages for example or have any other meaning.
This is the exit code returned by the process when it finishes; Android however does not care, but know that the error code should never be higher then 255.
Here is a list of standard exit codes - some process may use their own codes.
0 Clean Exit
1 General Error Catchall
2 Misuse of shell builtins
126 Command invoked execution error
127 Command not found
128 Invalid exit argument?
130 Termination by Control-C
255 Exit status unknown
Android does not care, no. This is a java thing -- you can use them for your own debugging etc etc.
Here's an example of system exit codes: http://www.opensource.apple.com/source/Libc/Libc-320/include/sysexits.h
But pretty much, anything > 0 means that its an abnormal exit. You can set it to whatever you want, but I'd just stick to 0 unless you're interacting with other things.
It just seems to be the accepted convention.
I have an application which simulate Agile scrum board,developed in java which takes commands through command line.For e.g. it takes command like:
"create user story"
One of the rules to develop this application says that:
Your implementation should return a 0 errno on successful completion, 1 for an error
what does this errno means? is errno some specific keyword ?And if its keyword,then how to return this?
I have used system.exit() in below manner. Is it correct way of using it ? I dont get 0 printed on console when the program is exited?
if(input.equalsIgnoreCase("quit")){
allbacklogs.saveAllUserStory();
System.exit(0);
}
Thank
errno just means error number.
0 means that program excecution went fine
1 (Or any other integer than 0) means that there was an error
When the program ends naturally, 0 will be returned, and when the program crashes for uncatched exception or error, 1 will be returned automatically.
So you don't actually need to do anything to fit that requirement. If you need to manually use System.exit use System.exit(0) on no error and System.exit(1) on error.
In Java, we use System.exit(int) to exit the program.
The reason for an "exit value" in C was that the exit value was used to check for errors in a program. But in Java, errors are reflected by an Exception being thrown, thus they can be handled easily. So why do we have exit values in Java at all?
exit values are returned to the calling program e.g. the shell. An Exception cannot be caught by an external program.
BTW When you throw an Exception it is caught by that thread or that thread dies, the finally blocks are still called for that thread. When you call System.exit(), all threads stop immediately and finally blocks are not called.
For the same reason.
Exit codes are exclusively used by parties and applications outside of the program for debugging and handling purposes. A super-application can definitely handle a return code better than trying to parse a stack trace.
Also, if you are creating an application for an end-user, you would much rather exit gracefully from your app than post a bunch of stack trace information, for a couple of reasons: one, you will just be scaring them with lots of crazy-looking techno-gibberish, and two, stack traces often reveal sensitive and confidential information about the way the program is structured fundamentally (giving a potential attacker more knowledge about the system).
For a real-world example, I was working on a Java Batch program which used exit codes for its jobs. A user could see whether the job executed successfully or not based on whether the exit code was "0". If it was anything else, they could contact technical support, armed with the additional information of the exit code, and the help desk would have all the necessary information based on that exit code to help them out. It works much nicer than trying to ask a non-technical end-user, "Okay, so what Exception are you getting?"
exit values are returned to the callers to signal the successful or insuccessful completion of the program. The caller may not be able to catch the exception and handle it accordingly.
For eg. 0 exit value means successful completion whereas non-zero return value means some error in execution.
Also, System.exit() will make all the threads in the application to stop at that point itself.
Long story short, Exit codes are simplified signals to the user who encounters an exception while running a Java program. Since we assume that most of the users do not understand stack trace data of an exception, these simple non zero custom code will tell them that something is wrong and this should be reported to the vendor. So the vendor gets the code and he knows the stack trace associated with that code and tries to repair the system. This is an abstraction provided by the programmers so that users don't have to read and report voluminous stack traces. A very good analogy here is the getErrorCode() method in SQLException class. This method also closes the current JVM that is running on the client machine. This implies that this terminates all the threads that are in the JVM. This method calls the exit method in the class Java.lang.Runtime. If you go to the documentation of this method, you will understand how virtual machine is shut down.
This is the link
http://docs.oracle.com/javase/6/docs/api/java/lang/Runtime.html#exit%28int%29
Below is piece of program I was using to simply Open and close the Internet Explorer from my command line program. im running my program with Java 6 on Windows XP OS:
Runtime runtime = Runtime.getRuntime();
Process p1 = runtime.exec("C:\\Program Files\\Internet Explorer\\iexplore.exe");
Thread.sleep(5000);
p1.destroy();
Thread.sleep(2000);
System.out.println("p1.exitValue(): "+p1.exitValue())
The exit value is : 1.
Javadoc says: by convention, the value 0 indicates normal termination.
http://download.oracle.com/javase/6/docs/api/java/lang/Process.html#exitValue()
Then I commented p1.destroy and instead of closing the browser from my Java program, I closed the window manually (File>Exit). In this case p1.exitValue started returning '0'.
My question is:
Why program returns exit code as '1' in first case? Does JVM treats p1.destroy() as abnormal way of terminating a program?
In general the 'exit status code' value is JVM specific or Operating system specific? I have seen some question where people have reported exit code value as '10', '34545' etc..
Thank you for reading,
Actually, that's two questions :-)
Almost certainly, IE itself captured the fact that it was being shut down externally and decided to return that error code (see 2 below). So no, the JVM doesn't treat p1.destroy() as a special case, but the affected process may.
Exit values are process specific, not JVM specific (and not even OS specific). In other words, a process itself returns a value to be used as the exit value. This makes sense when you think of the fact that there are ways to destroy processes which don't involve the JVM at all.
I should mention that there are cases where the process doesn't affect the exit code. Under some UNIX-like operating systems, if a process exits due to some serious fault (like a segmentation violation or a violent external shutdown), the exit code may be set by the OS to a value indicating this. From memory, it was something like 128 plus the signal number.
I have a C# app that runs a jar file and uses the System.exit code as a return value. A console window is displayed as a part of this jar, and if the user closes it (thereby terminating the jar) it returns an exit code of 143. The problem is that 143 (or any positive integer) could be a valid exit code if the jar completes successfully.
I need a way to manually set the System.exit code to a negative integer. Treating 143 as an exception in the C# app is out of the question.
As in Diego Dias answer,
The argument serves as a status code; by convention, a nonzero status code indicates abnormal termination.
If you really want to ignore that, and both the Java and the C# apps are in your hand, an easy workaround is to add 1000 to your System.exit return value in Java, when the jar completes.
Your C# application will recognize the successful execution by a return code >= 1000 and subtract it again. 143 is below 1000 and thus an error.
Acording to the java documentation you can use System.exit(int n), so just put a negative number as a parameter, also by convention, a nonzero status code indicates abnormal termination.