What happens when it All Goes Wrong?
In the first blogs in this series, I focused on how to avoid things going off the rails when you write an application, including the use of Program Test Data and how to interpret Program Errors for Java, Visual Basic, and Python. In this blog posting, I'll be looking at the different Program Termination and Return Codes are received when each of these three programming languages end.
Normal Termination is the result every programmer is looking for. This means is that the program was able to come to its natural conclusion without some type of failure. The three languages that we’re looking at present Normal Termination with slight variation:
● In Java, an exit code is not just used when things go wrong, but an exit code is generated when the program ends as it should. In Java, this normal termination code is System.exit(int). This creates the exception code in an integer format for later analysis.
● In Visual Basic, as with Java, an ExitCode is generated whenever the interpreter or application reaches the end of the program. A zero value shows that the program ended with no errors. Non-zero errors can be referenced to find out what kind of event caused the program to fail. Visual Basic uses the ExitProcess ExitCode statements to write the exit codes to memory.
● Pascal has a function that will return a function code c of P: with 0 indicating a successful termination. Python also uses a statement called the sys.exit. This statement performs the same function as System.exit(int) in Java.
Packing an application full of conditional statements designed to create Return Codes can cause the program to slow down, and the entries can actually create more errors due to the nature of inserting a purely error checking process. The forks in the coding road that conditional statements create cause complexity in the application, resulting in more potential for errors. Like anything else in life, this means that a sense of balance needs to be used to determine how much error checking to put into an application to give the application notification capabilities without burdening the application with unnecessary complexity. The process of using Return Codes is almost identical in Java, Visual Basic, and Pascal, differing only in the syntax used to print values to a log file or the screen.
Abnormal Termination Codes provide a rich number of clues as to why a program may have failed.
Java objects and classes give what are called Exceptions when something happens that might stop the programs progress toward a healthy conclusion. The two main types of exceptions are resumption and termination. Resumption Exceptions diverts the process to the Exception handler to correct what went wrong, and once it was able to recover, it attempts to reroute the application back to the point in the program where the Resumption Exception occurred. A Termination Exception results in the program coming to a halt due to an error that is so extreme that the application cannot recover.
Visual Basic has a library of Abnormal Termination Codes that can be referenced within the Microsoft Visual Studio IDE.
As Python is running an application in real time, errors can result in what is called a traceback message that lists the presence of an error and its location.
During the coding and troubleshooting process, print commands can be used to display the values of variables at various points during the application, so that the changes in their values can be tracked. This will often pinpoint where an algorithm has gone wrong by affecting the wrong variable or failing to update an incremented variable.
Python has an additional ability to provide troubleshooting information, called an Assert. Whenever the application hits an Assert statement, it pauses itself, allowing the programmer to test the values of various variables that are in play at that moment. Once the application is up and running properly, Assert statements are then removed to ensure the program runs smoothly.
Python is more focused on exceptions that are handled by the application developer.
The way you style your posts are very easy to follow and seems pretty personable compared to other people. It would make things nicer if you included images, but the format of the text and the way you word things is superb. With your posts, it seems like you really know what you are talking about. I have used Java before so I understand how that language works, but I have never used Visual Basic or Python so it is interesting learning from you the various characteristics of these languages. I can see how putting in more error checking might seem like a good thing to do, since after all, the less errors in the program, the better the program. But I can also see what you mean about more error checking possibly bogging a program down with more things it needs to process, or even becoming the cause of errors and problems itself, which is never a good thing.
ReplyDeleteIt seems like if there were any abnormal termination errors produced, the kind of termination I would want is a Resumption Exception since that seems like the program will try to recover itself and continue performing processing from where it left off. Compared to a Termination Exception which seems to quit out of the program altogether, resumption seems like the thing to go for. But of course there are certain cases I can see where a complete termination may be all that can be done, or what must be done to prevent other additional problems.