Project 12C - Program Termination and Return Codes

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.

Project 12B - Program Errors

All about Errors - Types of Errors Found in Java, Python, and Visual Basic

Design errors are the highest level errors that occur. They result from an architectural failure of the application, usually where a programmer is presented with one problem, and the application created addresses another problem. If the car won't start, repainting it might be awesome in another circumstance, but it doesn't address the problem with the car not starting.

Syntax errors in programming are the analogues of syntax errors in English composition. They are instances where the rules of language have been violated. Tools to catch Syntax errors are usually available in the Interactive Development Environment (IDE) that is being used to build the application.

●        In Java, syntax errors must be identified by looking between identification points where the syntax error has occurred to narrow down where the syntax error is.

●        In Visual Basic, Microsoft will highlight the syntax error via a wavy red line, just as it does for a misspelled or misused word in Microsoft Word.

●        In Python, explicit syntax error codes are returned for syntax errors at the point where the syntax error happens.

Semantic run time errors, usually just referred to as run-time errors, are errors that result of some type of program crash. Often these errors are non-specific, and often not the most helpful errors in the world. Exception statements can prevent a run-time error in an application from terminating the entire application. Different programming languages and environments handle these errors in different ways

●        Java provides the ability to narrow down where a run-time error occurs through the use of markers that identify the point before and after the lines of code that caused the run-time error, just as it does with Syntax errors.

●        Visual Basic gives exception objects at the point in the code where there is a run-time error, along with an error number and a message specific to the type of run-time error encountered.

●        Python has what are called Built-in Exceptions, which are class objects that are generated by the interpreter and give specific error codes that convey the nature of the run-time error.

Often, one error in an application can cause follow-on errors due to dependencies between objects in the application. Often, Catch statements isolate portions of a program where some error that could cause the application to crash.

Another common error type in beginning programming is the use of reserved words used as variable names in an application.

In Python, some of the reserved words are obvious, such as while, import, and print. Others, may not be as obvious, such as raise, global, and return. A full list of Python reserved words can be found on the other side of this link.

Because Java is purely object oriented, there are no concerns about global variables causing problems. There is what is called primitive types in Java, which act as reserved words.

A common error that is seen in Java is a case-sensitive mismatch, where a variable like "Cupcake" points to a different memory location and value than "cupcake", resulting in hard to track down errors.

Java does not require line spacing to run properly, but instead uses a semi-colon to call the end of a line. Python relies on carriage returns and indentation to segment and format commands.

So there it is - a quick run-down of the most common beginning types of errors, and some ways to avoid them, as you start learning more programming. Stay tuned for part 3…

Project 12A - Program Test Data

Program Test Data and Troubleshooting Tools for Java, Visual Basic, and Python

The next three entries in this blog are designed to explore basic processes needed to write better, more bug free applications. To provide a reference for the methods that will be discussed, I will examine how these methods pertain to Python, Visual Basic, and Java.

One of the first methods to avoid bugs involves creating a framework for checking the validity of the data being entered into variables in an application. This process involves making sure the variables are declared, and that data is entered within the correct range, so that it “passes the sniff test”. If a variable is supposed to be either a true or false entry, and someone tries to insert “3” into the variable, things are not going to go well in application land. The solution is to declare that the variable has a Boolean data type, which will only accept a true or false (or a 1 or a 0, depending on the language). For numeric data, defining minimum values and maximum values for each variable will ensure that the correct range of data is entered. This can also increase the security of the application by ensuring that enormous variable values aren’t entered for the purpose of crashing an application in an unprotected state, possibly allowing a hacker or virus to have elevated privileges into core computing components.

Let’s look over the data types that are used in Java, Visual Basic, and Python:

●        Java has only three data types: Integer, Boolean, and Character. Java has a defined set size for data types no matter what hardware platform the Java application is running on.

●        Visual Basic has the most data types of the three languages being compared, eleven in total: Boolean, Byte, Single, Double, Date, Currency, Integer, Long, String, Variant, and Object.

●        Python has 10 basic data types: Numbers, Integer Numbers, Floating-Point numbers, Complex numbers, Sequences, Iterables, Strings, Tuples, Lists, and Sets.

Declaring variable data types early and being very detailed and consistent with data type declarations is critical to avoiding unnecessary junk data from causing logic problems. This is a circumstance where painting outside of the lines is not a good option. Define the type of data that a variable should contain, and ensure that all data is correctly formatted. Part of the program architecture must include an acceptable range for all variables used, with the minimum necessary chosen to conserve memory space wherever possible

Each of these three applications also has various methods of detecting logic failures. In all three, the use of programming tools will often find problems before the program has ever been compiled to run. A compiler or Interactive Development Environment (IDE) will show the programmer in advance that there are basic syntactical errors or exception errors (things like a numeric divide-by-zero error, for instance). Another tool used by Java to assist with troubleshooting is an exit code when a process thread is no longer able to continue execution, either naturally, when the program reaches its natural conclusion with a normal termination code, or some other non-zero termination code that results from some type of error.

Java will provide output (called a dump) of the elements and methods that were in use by the module at the time an error occurs while the program is running (called run time errors). A programmer can also create test print statements that can be removed at a later time that create virtual bookmarks to allow the programmer to see where a sudden failure in the code may have occurred. This provides a way to monitor the progress of the application as it goes through its modules toward completion.

Java has built in aids to debugging programs for common errors such as Java PathFinder, Java DeBug, and the tools that are built into various IDE platforms. The Java Bug database is a well maintained database of common application bugs that can also assist in the programmer in troubleshooting issues.

The simplest description of Logic Testing of an application is that it provides a test every available path of logic in the application. Logic Testing, also called glass-box testing, shows what elements of the program are not executed (orphaned logic threads). This process allows for compartmentalized testing of individual sections of code, which should reduce the amount of application testing needed. Finally, it provides a quantitative method of comparing progress in addressing application bugs and errors.

Project 11G - Translating PDL – Program Design Language into QBASIC Code

How PDL is like a Good Corporate PowerPoint

I've already talked at a high level what Program Design Language (PDL) is. This blog entry is to help those who want to know more, but are too lazy to read a serious work on the subject. PDL is designed to read very much like a high level coding language. In this blog entry, I'll use QBasic code as my example of a high level language (go with me on this, Java-heads). Even though it is soon going to go the way of the dodo, QBasic is still used in education to develop a basic understanding of programming structure.

Both PDL and QBasic share many common words in their lexicons, such as If, Else, End, and Return. PDL coding uses a large vocabulary of keywords that create a natural language fit, such as Assign, Write, Display, Print, Store, Copy, Delete, If, Else, Otherwise, Loop, and While. QBASIC common words include While, Until, For, Next, Goto, If, Then, Input, Loop, and Answer. Though QBasic is a little more rigid and stilting than PDL, in both cases these languages are using common English words to describe how they are carrying out their functions.

As you can see, these two languages are very close in their vocabulary and structure, as if they were two different dialects of Chinese in nearby regions of China. PDL, by design, is a descriptive language that can be used to narrate the algorithms of an application. Once the story of the logic flow is written in PDL, it is a fairly trivial task to re-write PDL into QBasic code to take an application from a theory that it will run well, to a true test of your coding prowess.

Both QBasic and PDL have the same visual format, where lines of code are differentiated in which hierarchy they are involved with through the use of indented text. Both languages have the ability to show comments, which are used to communicate with programmers who will come after the programmer writing the application, telling them what the purpose of each section of code is.

The process of creating PDL code and then translating PDL into QBasic code has its purpose. The narrative nature of PDL forces the programmer to think through the use of variables and ensures that the programmer has planned all of the logic being introduced in the application. This is similar to the way that saying a speech out loud, instead of merely reading it, will uncover errors in grammar simply due to a student hearing the flow of words out loud. Though human readable, a PDL program can’t be compiled and run on a computer. In order to test a section of code that was generated in a PDL environment, it must be run to see if theory meets practice.

Using PDL to explain a QBasic program to yourself and others is similar to creating a PowerPoint presentation for a management group to review a project at work. A project from a technical engineering group may involve a huge amount of technical detail, sometimes with hundreds of pages of settings and configurations, all of which is incomprehensible to a management committee. They need a way of consuming and digesting information that is quickly and easily understandable, so that they can make decisions on allocation of company resources for competing projects, and provide project managers with guidance on company priorities. There is no way someone could take one of these PowerPoint presentations, and go off and configure a complex system with them. They are “manager readable”, just as PDL is “human readable”, designed as a tool for oversight and analysis.

Project 11F - Solving Simple Problems Using Algorithms and a Program Design Language

Crawl, Walk, Run - The Evolution from Algorithm to Useful Code

Most babies transition the way they get around the world by crawling, then walking, and finally running. Those who make the jump from crawling to running without building the walking part often suffer from more falls and tumbles. Writing useful, efficient code can be the same way. A talented programmer can make a jump from idea in their head to code that a computer can run, but once a program becomes sufficiently complex, stream of consciousness software writing is more likely to take longer than a process that involves drafting out ideas in advance of writing code. Software that is complex enough to necessitate a team building environment requires some means of ensuring that everyone is moving in the same direction in the design and development of an application. Writing complex software code without a roadmap ensures that it will be hard to maintain and have limited use as time goes on.

How can you enhance the chances that a complex design will be successful (delivered in-scope, on time, and on-budget) in the end? If writing the line-by-line code of the application is where the programmer’s feet meet the ground, the roadmap to the programmer’s destination is the application flowchart, and the Program Design Language (PDL) and Pseudocode is what provides the programmer with the detailed instructions to get through the jungle and safely home. With these tools in hand, a programmer has a reasonable chance of writing concise code that follows a complex, high level design with a minimum of errors.

Flowcharts resemble maps more than any other tool used to document the flow of logic in an application. Flowcharts provide a visual representation of the logic and algorithms that are used. It can help a programmer sequence logical operations in the most efficient way, highlighting logical errors (loops without ending conditions, forks in logic with abandoned logic threads, etc.). If an application is complex enough, simply having a flow chart is often not enough, just as detailed instructions tell a traveler where and when to make the turns in a journey PDL or Pseudocode provide human readable code that is used to document the specifics and visualize a logical process that will be used by an application.

PDL is plain language coding that is designed to be written by human beings and read by human beings, never for a computer's eyes, allowing the programmer to put their thoughts on how a program will be executed on paper (or pixel, as it were). Pseudocode can be used as an intermediary step between PDL and writing actual code, providing an even more detailed view of how a complex algorithm will be executed by an application. Starting to jump from flowcharts to writing actual code is kind of like writing a complex essay in pen. Though it can be done, it prevents ideas from being developed on the fly and lead to more errors that result from an inability to translate ideas to text accurately.

To break this idea down to a level even my grandmother can understand, let me apply these ideas to a daily task that is too complex for me to wing it: getting my daughter’s diaper bag ready at 4:00 A.M., well before I’m fully (or remotely) awake. Something as simple as this, based on hard experience, is well beyond my ability to do right without some tools. I have a sketch drawn by my lovely wife of the contents of the diaper bag as it should be, drawn in the IKEA style, hanging next to the door. This is my equivalent of the flow-chart. In addition, there is a check list of items below that, written so that my sleep addled brain can make sense of it:

1.      Inventory the supplies in the diaper bag

2.      If Diapers less than six, add some

3.      If the pack of wipes is less than half full, put another pack in

4.      If there isn't a fruit puree, add one

5.      If there isn't a vegetable, add one

6.      If there isn't a meaty jar of some type, add one

7.      Was the spare outfit used after an accident? If so, replace it with a clean one

8.      Finally add 22 ounce bottle of milk, and a full 12 ounce toddler cup of fresh, cold milk

My wife isn’t demeaning me. I asked for help after the frustration of delivering Ava to the sitter over and over again missing something important. It isn’t until later in the morning that I start to become a high level thinker, capable of preparing complex diaper bags without assistance.

A programmer that can set aside his or her pride in their ability to juggle many tasks, and use simple tools for organizing complex applications or tasks ends up being more productive. Think about that next time you are thinking that flowcharts are for wimps!

Project 11E - Elementary Program Design Structure Model

How a Program can be like Alice in Wonderland

The White Rabbit put on his spectacles. "Where shall I begin, please your Majesty?" he asked.

"Begin at the beginning," the King said gravely, "and go on till you come to the end: then stop."

Alice in Wonderland, Chapter 12.

Without a guiding structure, how can anything be accomplished? If you don’t know where to start, you won’t know how to stop, and as elementary as it sounds, anything you do will end up as a mess without a basic, recognizable structure. The Elementary Program Design Structure Model is a framework for organizing a program into a logical beginning, middle, and end, much like the structure of a good movie. Why is this form necessary? When another programmer is reviewing the written code, this structure helps someone else to understand what is being done, because the program is following a well understood structure.

In the Setup of an Elementary Program Design Structure Model, a programmer will list the variables that are being used. This process is often referred to as the Declaration of Variables. In this section, it is good form to provide a significant amount of documentation in the form of programming comments that list the purpose of each variable. Also in the Setup, variables are Initialized, meaning that they are either zeroed out, or they are set to match the first record from the program input that will be used. This process ensures that, if the memory space had been used by another application that didn’t close out the memory properly, then there would be no unknown values that would create false values later in the application. As you would expect, the Setup section would only be done once, at the beginning of the application.

It is in the Process section of the application where the rubber meets the road. This is where the action of the application happens: Arithmetic Expressions, Logic Loops, the dynamic use of Arrays, and other Logical Expressions are used in this section. Once the foundation for the application is created in the program Setup, the variables that were defined are now manipulated and processed to resolve the central questions that the program is written to answer. Arithmetic expressions take the initialized data and apply algorithms to the data to get a resulting set of answers. Loops are used by the application to repeat a process or calculation a number of times, based on either a counter, or on a logical condition that creates a break in the Loop. Arrays are used in the Process section to create relational models of the data as it is being manipulated. Finally, Logical Expressions are used on resultant sets of data to determine if certain conditions have been met, such as the purpose of a Looping statement having been satisfied.

Once all of the data being manipulated in the Process section of the program has resulted in the answers being sought, then it is time to Wrap-Up the application. This process is as short and simple as the Setup section. It involves closing out any and all open file structures and releasing memory used by variable structures that have been called up by the application.

This process of organizing an application is almost painfully simple, but without it, the results would be a dreadful waste of time, just like a movie without a plot is mind-numbing. If you were going to make a home movie, you would create a Setup, where you introduce the characters and prepare to set things in motion by giving some background and giving the audience an idea of what they are getting ready to accomplish. The main body of your movie would involve the plot mechanics, where the plot would build, twist, turn, and finally deliver a climactic end to all that was building throughout the movie. Finally, just as a movie that goes black the moment the climax is over is not very satisfying (leaving the viewer to wonder what really happened), there needs to be a Wrap-up process to the movie, letting everyone know what eventually happens to the characters as a result of the crazy hijinks they experienced throughout the movie.

So there you go, you have a structure to either write a program, or film a movie. Or both?

Project 11D - Program Hierarchy – Tracing Design Output to its Source

Pyramids, Rivers, and Broadband in Wealthy Neighborhoods - How Hierarchy Creates Efficiencies

Egypt, Sudan, Nigeria, Greece, Spain, China, Mesoamerica, North America, the Roman Empire, Medieval Europe, India, and Indonesia all built pyramids. Why is that? The answer is a hierarchical architecture. It is the only design and building methodology that will allow massive, complex structures to be built with the materials on hand (stone) during the time of an ancient civilization. A hierarchy is a system of structure where subsequent elements are reliant upon prior elements, and all elements in the structure are linked via this dependency. A hierarchical structure has elements of ranking, levels, and peering between levels. When developing a complex application, the same logic applies.

If an application is organized in a hierarchical structure, then it follows a process of logical flow of data and algorithms from top to bottom. By structuring which modules are called by other modules at different layers, the programmer creates a structure that is easier to understand and troubleshoot.

A Program Hierarchy is very useful in determining the flow of input data, for instance. As an analogy, think of a large rainstorm falling on hilly terrain. The gentle rain falls on a hill, and the run-off from this rain creates a small stream. These streams then form a junction to form rivulets, which in turn junction across the region to form raging rivers that eventually will find their way to an ocean or sea. Like the original drops of water, the data that is inputted into an application will flow through the levels to a known conclusion, if the program is organized hierarchically as the hills and valleys of the terrain is organized in elevation. This process allows a programmer to validate test data points inserted into the logic of an application. Test data will have a known outcome after being processed, following a pattern that is made predictable through the use of a hierarchical architecture.

A key to developing an application in a hierarchical fashion is through the use of algorithms that manipulate data and perform functions in a predictable pattern. The concept of peering is important with algorithms. In a complex program, there is rarely a single process that is being performed. Instead, there are classes or stages of algorithms that are manipulating different kinds of data. One section of a program might be classifying users based on demographic data that is being pulled from different sources, and another section of a program might then create a map of telecom broadband upgrades to broadband switches in neighborhoods by ranking local neighborhood demographics and income (I hate to tell you, but this is how the phone company determines what neighborhoods get newer, faster broadband availability first...). It would be inefficient and complicated to perform this kind of sorting and ranking over and over again for each type of demographic input (average income, number of vehicles per household, number of children in household, average level of education, etc.). Peering the same type of algorithms on the same level of an application allows for a more logical, natural flow of data manipulation, allowing for both greater efficiency of programming (more things done with fewer lines of code through reuse) and greater ability for a number of application developers to work in tandem.

As an example of the use of hierarchies in personal life, look to how complex volunteer organizations are organized. Neighborhood groups are peered together, and the leadership of a neighborhood organization might meet in city wide councils to discuss and unify a position important to the communities as a whole. The city wide volunteer councils might then send representatives to a state-wide organization that interfaces with government groups at the state level to advocate for individuals in neighborhoods across the state. In this way, a person’s desire for change has a way of flowing from their block all the way to a state capital and be heard by the correct people who can affect change for the better. See how the forces that cause drops of water to form the Amazon and blocks of stone distributing the weight of The Great Pyramid of Cholula can also allow an individual to be part of a democracy? Hierarchy Rules!

Project 11C - Systems and Program Mapping Tools

How to use Computer Programming Diagrams to Figure Out How the Organization in a Company Really Works

It is exceedingly rare for someone to have such an incredible memory that nothing is left out. Though having a photographic memory is a common science fiction plot, in reality it doesn’t exist. This is why, unless you are only going to write something as complicated as Hello World, you should leverage tools that will help you keep the program you are writing as cohesive and clean as possible.  The three tools I’ll talk about in this article will be System Flow, the use of a Structure Chart, and the use of Detail Program Logic.

System Flow - A Systems Flow Chart is a visual diagram of each module in the program showing how each module interacts with the others. This diagram shows all of the inputs and outputs for a module, so the programmer can follow the flow of data from one module to the other.

Structure Chart - A Structure Chart is used to view the overall flow of logic between modules in a program, lays out in a hierarchical manner that allows the programmer to see the top-down, branching nature between modules. This visual medium creates a map that will allow the programmer to follow the flow of processes down through the modules.

Detail Program Logic - A Detail Program Logic chart is a diagram of the flow of program logic through the modules, showing the branching of logic in the application. Following the logic from left to right flow of logic, the programmer should be able to see the impact of different logic sets on the variables used in an application.

These three diagrammatic methods together allow the programmer to predict how the program will operate, before the first line of code is written. In order to create these diagrams, the programmer will need an understanding of: the purpose of the program or modules of the program; the logic involved in the program; and the variables being used. Even though things rarely turn out exactly as they are planned, it still creates a fairly high level of certainty that a programs logic will be successful when written.

Outside of computer programming, one of the best examples of how logical and relationship oriented charting can solve problems is when a business consultant comes into a corporate environment to improve the business process. A variety of organization charts are key tools that are used to determine relationships between people, lines of responsibility, and determine if there are inefficient silos within a company that are constricting its ability to be reactive and compete in the market. A consultant might, for instance, take the official organizational chart, and interview key people who are at the nexus point between organizations, and ask them who they report to, and who are their customers. Many times, a consultant will find out that, while there is a simple “official” reporting structure, there are many “dotted line responsibilities” that create inefficiencies in an organization. Once the consultant defines the informal business process, and overlays this discovered business process against the official organization chart, the consultant is able to develop a better organizational structure that accomplishes the same goals for the organization with a much simpler structure. This same process can be accomplished with a complex program with many modules that are interlinked.