Good Programming Techniques, Part 1: Exceptions

October 8, 2012 by Adrian Stolarski

Good Programming Techniques, Part 1: Exceptions

In a previous article related to good software development techniques, we learned SOLID principles and three-layer architecture. For the three-tier architecture, of course, we come back again, because I do not think this subject has been completed. In this article, however we will be learning another of the good programming techniques and the use of exceptions. It is one of the most important issues each of the developers is really dealing with. This article will consist of two parts and I really invite you to read both.

Perfect introduction to the use of exceptions

Very often, when we use software something goes wrong. Do you still remember the blue screens in Windows? As you probably have not failed to notice, handling emergencies in each application is really one of the most important aspects of the software. Note that we really do not live in a perfect world. Both hardware and software include hundreds of errors. Then there are otherwise very intelligent users. Truly the life of each of the developers is not easy. But in spite of all, employers and users require us to deal with it. Fortunately, with the great help of the software development process, exceptions come to us.

Fortunately, this situation will never remain the same. Note that humanity really would come to nothing if it did not benefit from the achievements of previous generations. Maybe we would arrive at a stage where every day we invented the wheel or fire. Looks very much like the situation with software development. Notice how long it takes us to write error handling, if we want to create it from scratch. A much better and more efficient way is to actually benefit from the work of other developers who have encountered a similar problem. This situation is now on the agenda. Once my supervisor said, “When you create software, it take three times thirty percent of the work of others and ten percent of your code to be really innovative.”

What happens when the program encounters a problem that it can not handle?

In this case, we can really use several mechanisms. Some of them are more efficient, and others will be much less so. Let’s not talk about which solution is better and which is worse, because everything depends on what strategy we choose when designing our program.

If you find a critical operation, each program may simply end. Today, when we are dealing with object-oriented programming and high-quality software, a program that behaves in this way is practically useless, but once at the beginning of software development, such activities are on the agenda.

The program may also be in the event of such a situation to pass a value whose sole task is to represent the error. This solution is not always possible to implement, and in fact it is very cumbersome to use. There are no major problems if the program has only one type of error. Then we give it a value of 0 or 1, and set such a simple semaphore. But what happens if and when our program offers several different errors?

Our software can do one very unpleasant thing: to provide the correct value, and remain in the incorrect state. This is a very bad output for each program. We then have to deal with the global error codes, which really does not work in concurrent applications. In addition, is the case that we are dealing with a very troublesome operation. What has always amused me with this approach to handling errors? Moore can remember right? If the application has a small error, it really has not met its true size. In the information world this thesis is actually very true.

The program can also call the function or method provided in case of errors. This solution is much better than all the others that have been mentioned above and is derived from the structural software languages. Remember the good principles of software development in C for Unix / Linux? Then when the software encountered some issues or reported a bad parameter for the program, the program ended and printed on the console a list of available parameters. Additionally, you can of course write your own handler to handle errors. This solution is very often the case with websites written in PHP.

The best solution that can be offered is to always throw an exception. It is based on the fact that if the function encounters a problem that it can not cope with, it just throws an exception, in the hope that in a place where it is called, the program will know what to do with it. This function that supports all the problems of this kind must always be in some way able to signal the desire to catch the exception.

Exceptions – why are they so good?

The approach for handling exceptions is really a very good alternative to all traditional solutions. They are used when you know in advance that all previous approaches are not very adequate  or elegant. They are mainly used when you need an explicit separation of code responsible for errors or exceptional situations from the rest of the code. With this solution, all our programs are much more readable. The mechanism which is used to handle exceptions really supports the regular style of error handling. By using this approach it strongly simplifies the interaction between all parts of programs, even those written separately and attached in the form of libraries.

Of course, there are also programs that require user interaction with bugs. This approach nowadays is unacceptable. We can agree on this one thing, unless you create your own software. You are not a programmer and do not really know the application thoroughly. Each well-written program will never be rerouted by the balance of incomprehensible messages.

Exception handling is really a very difficult task. Well they write that program management is an art for art’s sake. Exceptions use an unstructured error handling method, which makes the control flow of the application not really local at all. To put it in simpler language, understood by every programmer or computer science student, the mechanism for handling exceptions is really a non-local control structure. It uses stack winding and can be identified and treated as completely different return mechanism.

If we look at it historically, exceptions were created just as objects to determine if a proper mechanism will handle errors and many other situations. Their main purpose is to facilitate the handling of errors in the programs, which are composed of independently designed components. Please remember that exceptions only highlight the problems, but never in themselves are problem. Remember that we live in a civilized world and must never blame the messenger for the fact that it delivers bad news.

What is really wrong?

It really depends only on the programmer. It depends what the unique situation will be in the application. When writing programs, it’s actually a very difficult task. If you write software, before taking an exception, always look for answers to two fundamental questions:

  • Can it be considered for some special event that takes place in most versions of the program?
  • Can it be considered as an error event that is planned and that is supported?

The answer to both questions is obviously yes. Unique does not mean that the event almost never occurs. There is also an event, which is potentially catastrophic. The exceptions can be thought of essentially in only one way. These are usually situations in which such a part of the system is not able to perform a specific task. The application of this approach is that any shares related to exception handling should be reported as little as possible. Certainly it must be much rarer than calling the same function, otherwise the program will be unreadable.

Very often the use of exceptions is allowed in the process of software testing, for this mechanism is usually very useful during the process of software development in the TDD methodology. Then we have full control of the program and we can determine what to expect, but this subject has of course come back.

Exception class and grouping exceptions

What really an exception? Mostly it is an object of a class that represents an exceptional event. The code that detects the error and which is usually some type of library declares a desire to create an object. Then you have to signal a producible program. This is done by placing a catch clause in the code. As a result of this application clause a collapse of the stack occurs, which lasts until you find the appropriate catch clause. This clause is found directly in the function, which in any way caused the exception.

Exceptions are really the same laws as the rest of the objects and classes. Also they create their own families and are between the mechanisms of inheritance. Sometimes we do not forget about a specific exception, and grab all the family. By using these mechanisms, it is possible to catch exceptions not only individually, but also the entire family, not to miss any of them.

Exceptions in programming languages

Virtually any object-oriented language provides a programmer with a very useful technique. This is what is called in everyday life structured exception handling. Its most important task is the proper response to errors. To put it in a nutshell, we say that the whole concept of exception handling provides a top-down structure, that for each detected error it will create a separate object exception. Then it is transmitted, together with the overall control program of a specially designed code. Theoretically, it is said that the exception object can simply be tossed, thrown, or returned. This can also take place between sections of the code. For example, it can generate an exception in one part of the code, while the second simply perceives it.

The use of exceptions has many advantages. The first and most important advantage it is an object of certain properties. In this way it is subject to all the laws that govern other objects. Another thing is that if an exception is not caught by the application, each community will complete its operation and crash on the most ordinary mistake. Another advantage is that the code responsible for detecting and handling errors should not really be in a place where these errors occur. Another advantage is that the development environment uses exceptions for all errors. Both the platforms .NET and Java thus correspond to the errors of all kinds.


One article is definitely not enough to show all the benefits derived from the use of exceptions. What’s more, it’s definitely not enough to show the correct structures. For my practice, I know that the idea of exceptions and understand all of their applications, and this is a topic that in future work will be enormously useful, as a series of programming techniques, for a good number of reasons. The most important of them is the fact that thanks to exceptions, we are able to understand all aspects of good habits while creating commercial software.

In addition, it is thanks to  the application of exceptions that we are able to properly carry out the process of software testing. So we see how it is a very useful tool. With it, we can even determine what is the ideal situation, and how it has become so. This speeds up the process of testing the code by several times.

Until I finish topic of exceptions, you do not see the point, so we will move on. In subsequent articles in this series we will be logging exceptions and giving you some tips of when you really want to use exceptions. I’ll show the library and tell why it is really worth it to use it, and then again we’ll get back to the multi-application architecture, since I got a few e-mail messages to enliven the subject. At the end we will create good habits of coding. Thanks for your time you have devoted to reading this article.

Posted: October 8, 2012
Adrian Stolarski
View Profile

Adrian Stolarski is a freelance security tech blogger, specializing in Java, PHP, and JQuery. In his own words, he does the hard work of training the unemployed. Currently, he handles Evaluation Visualization for real-time systems with XWT and Eclipse RAP. If he sees that something works, he asks how it works and why it works, then sets out to make it work better. A researcher for InfoSec Institute, he currently lives in Poland, but plans to move to London.