basically everything is run by the system and it needs to know after the operation as what actually has happened..whether it was successful or unsuceesful..this communication is done by exchanging the exit code..
Not exactly... the API documentation for the method says only this:
The API wrote:Terminates the currently running Java Virtual Machine. The argument serves as a status code; by convention, a nonzero status code indicates abnormal termination.
You could certainly invent your own conventions about what various status codes mean, and perhaps somebody has invented the convention you describe there, but if they have I've never heard of it.
It's pretty uncommon for people to write Java applications where the System.exit() status code means something anyway, but I suppose if you were writing a lot of little Java applications which were meant to be run by shell scripts then a convention like that might be a useful thing.
Paul Clapham wrote:You could certainly invent your own conventions about what various status codes mean...
@Sultan: But you need to be very careful about that.
For starters: (as Campbell said) using System.exit()at all is not generally a good idea.
Secondly: Although the return code is nominally an int, some execution environments - Unix shell scripts being just one - may not recognise it as such. I'm pretty sure, for example, that bash only uses the last 8 bits (unless it's changed since I was using it), which means that the maximum code it can "recognise" is either 127 or 255.
So don't start designing elaborate return code systems until you've thoroughly tested them - on many platforms. :)
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
System.exit(0): Termination under normal conditions.
System.exit(any +ve number): Termination which you thought and might have gone wrong. Can be considered as an error.
System.exit(any -ve number): Termination which you've not at all expected to occur, might be due to h/w failure, others ,etc. Can be considered as an exception.
That is obviously the convention you are using in your current app. There will be different conventions for different people and it doesn't matter which you use as long as you retain 0 for normal exit.
But I still think frequent use of System.exit is a “code smell” and you are probably producing bad code. It is a bad idea to use System.exit at all.
I believe System.exit(<some number>) is a holdover from shell scripting and other old programming techniques. I might write a script that looks for certain files to delete. That script would be called by some other program/script written by my colleague Bob. He and I would agree on what the return codes mean. We might say that 0 was "everything is fine", 1 is "I didn't find any files to delete", 17 means "There was a file I wanted to delete, but didn't have permissions to do so...etc. As long as Bob and I agreed on what the codes meant, what we used didn't matter.
Then, if Mary and I were working on a different project, she and I could come up with some OTHER set of codes that mean different things. But again, as long as Mary and I agree on what the codes are, everything is fine.
Now that we're in the more advanced programming world, these conventions and methodologies are a little outdated. We didn't HAVE exceptions back then. Inter-process communication was very complicated back then, so simply passing a number worked rather well.
Short answer though it: don't get hung up on the difference between the two. the number is simply a value being passed back to the calling program - which could be the OS, it could be another java program, it could be cron...
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
posted 4 years ago
fred rosenberger wrote:. . . back to the calling program - which could be the OS, it could be another java program, it could be cron...
Or it could vanish into some sort of cyber‑limbo never to be seen again.
get schwifty. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop