Programmers often treat all kinds of errors the same, especially when a user interaction is involved.  The problem is, not all errors have the same “meaning”, and not all errors should be handled the same way.  If, as a User, I attempt to use the program for something, and it reports a message target at a programmer (displaying a stack-trace, for instance), it can be confusing.  As a High-Level programmer, if a library call fails but my code gets back few details (getting only ‘There was an SQL error’, without the SQL statement that caused the error), it can be just as frustrating.

What do you mean by low-level or high level?

There usually different “levels” to an application, and each level has a specific type of concern.  Errors on lower levels should be filtered up in as appropriate a manor as possible, so that the higher levels can handle them as gracefully as possible.  Applications can have many different layers, but conceptually they can usually be represented in exactly four levels. What are those four layers? I’m glad you asked, because I’ve listed them below, from highest to lowest.

The User

This, of course, is the person using your application. Most often they are a human being, but someday users may include Artificial Intelligence or Extra Terrestrial entities.  Users are often task-oriented, although some of them are naturally explorers.  Task-Oriented users are more damaged by unexpected errors. Exploring users are more interested in seeing what is and isn’t possible, so errors often define a boundary for them, but these users are also most likely to find bugs in your application.

High-Level Code

This is sometimes called the “Domain” level.  The public methods in these classes are often task-oriented, and the class often define nouns that the User would be able to identify with.  Code in this level translates between user requests and low-level requests. This is of course an idealized definition, but the closer to this definition you can make your reality, the easier to maintain your application will be.

Low-Level Code

This is the library or framework code.  Code in this level usually is used to handle resources, and to actually get things done.  Most Low-Level code is “possibility” oriented. The API defined allows you to do simple, atomic, operations that might not be meaningful on their own, but can be strung together in a useful manor.

Resources

These are “external” things used by the application. Some examples are memory, files, databases, and sockets . Consumable (memory, disk-space, etc…) resources can run out unexpectedly, even if you “check” before hand.  Many resources fail for various reasons, for example sockets might fail because of a disconnected wire, files might fail because of a physical disk error, and database operations might fail due to overloaded CPU or low available memory.

Note, that there can be some “blurring” of levels, depending on the project you are working on.  For example, the developer of an HTTP Client library is probably writing “high-level” code, in that it represents the domain of HTTP, and provides “task-oriented” interfaces.  However, when that HTTP Client library is used in an application, it becomes “low-level”, because the User probably doesn’t care about the HTTP Protocol, and instead only cares about “downloading a file” or “viewing a web-page”.

From my experience, each of the levels correspond to a different kind of error, and those errors should all be handled differently. The likelihood of most of the types of errors can be managed, but not eliminated completely.

Error Handling

Handling User errors

This is the highest-level error.  It is caused by a user doing something they shouldn’t.  Most commonly this means the user entered an invalid input somewhere.  Whenever possible, the User Interface should be designed to prevent user errors.  For example, if you need a date then you provide a “Date Widget” and if you need a number you disallow non-numeric input.

Sometimes, it isn’t feasible to simply “prevent” user error.  In this case, the user input must be validated.  The best place to validate it is in the High-Level code.  Since this code is closest to the user, it has more knowledge about the user.  The High-Level code knows whether to pop-up a dialog box, print a line to the console, or update a form with error messages.

It may sometimes useful abstract the “error reporting” interface, so that it can be reused by different  UI interfaces. For example, domain level code might be used in a Web App, as well as a native GUI app, or even a command-line app.  Having an reusable interface for reporting multiple user errors helps in porting to new user interfaces.

Usually, it should be considered a bug in the high-level code if invalid user input causes a lower level exception. Low-Level code must verify the input it receives from higher-level code.

There are times, however, when it is infeasible to verify before hand whether an input is valid, and the validation must be handled a lower-level code.  In this case, the lower-level code should report the error to the higher level code, which should handle it and pass that information on to the user in an appropriate manor.

Handling Bugs

Bugs can happen in either low-level code, or high-level code.

In High-Level code, it means that some method (often a user task-oriented method) has violated some constraint, or failed to handle a lower-level error. In Low-Level code
it means that a method (part of a framework or library) has violated some constraint, or failed to properly handle a Resource Error.

First and foremost, it is rarely appropriate to show all the detail of “bug” caused errors to the user.  Most users would prefer not to experience bugs at all, but because this is the real world, we have to handle the bugs some how.  Most times, its enough to tell the user “There was an internal error.  Click ‘Report’ to send a bug report.”  The bug report should include any useful state information, but absolutely must include a full stack trace.  If possible, the high-level state should be recoverable, so that the user doesn’t lose any of their work, and can try either a slightly different approach, or wait for a bug fix.

The number of errors of these kinds can be reduced by Unit Testing, improving API design, Integration Testing, and User Testing.

Resource errors

These are Exceptional Circumstances.  Resource errors can be caused by bad data, connectivity issues, database constraint violations, file corruption, file-not-found, out-of-memory, and many more uncontrollable problems.

Resource errors should be reported to the user with as much detail as is likely to be useful to them.  If the user specifies a file, and that file is in the wrong format, this could be treated as a user error, and the user should be informed of the file they chose, and what was wrong with it.  Low-level code should report to higher-level code something along the lines of “I expected a FOO file,” and the higher-level code should report something like “The file c:\my.bar is not a FOO file. “  If a file can not be found, an appropriate message should be displayed, etc…

For this reason, low-level code which handles resources should report errors with as much structured information as feasible to higher-level code.  The higher-level code can then query that structure and produce an error message which is appropriate for the user.  For example, an SQL error at the lower level might mean different things; Typically duplicate a record might a User Error, but a syntax error is likely Low-Level Programmer Error.

There is far less that can be done to reduce resource errors, as they are often caused by external circumstances.  Often times using redundancy can reduce the frequency of fatal errors, but the errors themselves will still occur, and should still be handled appropriately.

When designing your system, you should decide carefully which type of exception you want to throw. You have basically three choices: Errors, Exceptions, or RuntimeExceptions.

For unchecked exceptions, generally Errors shouldn’t be thrown directly, and RuntimeExceptions should be thrown (only) if the programmer could have prevented the exception before hand. This last point is arguable, but as a rule of thumb, works pretty well.

Checked exceptions should be used when a condition might occure, outside the programmers control, that isn’t what a typical work-flow would expect.  Check exceptions, if they can’t be dealt with, should bubble up to a user in an appropriate way.  The user should then be given an opportunity to decide what to do, such as retry the operation, report a bug, or go eat lunch and forget about it

Now comes the interesting part. Circumventing checked exceptions.

There are at least two ways to throw a checked exception that isn’t actually checked.  Like with most of my esoteric Java features, they shouldn’t be used in production code. Both are hacks and both are ugly.

The first approach:  Class.newInstance().  Class.newInstance() will propagate any exceptions from the constructor to the calling code.  If your constructor throws a check exception, it will leak from Class.newInstance();

import java.io.IOException;
public class NoChecked1 {
   NoChecked1() throws IOException { throw new IOException("Leaked!"); }
   public static void main(String...args) {
      try {
          NoChecked1.class.newInstance();
      } catch (InstantiationException e) {
      } catch (IllegalAccessException e) {
      }
   }
}

The second approach: Thread.stop(Throwable t). stop(Throwable t) was deprecated a while ago, but Thank God Java Is Backward Compatible. calling this overload of stop will cause the thread to spontaneously throw an exception, checked or otherwise.

import java.io.IOException;
public class NoChecked1 {
   public static void main(String...args) {
      Thread.currentThread().stop(new IOException("Leaked again"));
   }
}

Yikes. Don’t try this at home kids.

The truth is that using any of those approaches to design may well leave you with a brittle, unmanageable, ugly mess. Personally, I strive for the “real-life concepts” as one top-level goal. The other top level goal is decoupling. Transcending all goals, of course, is creating a “correct” program. Not necessarily “correct” in the academic sense. I don’t verify every algorithm I use, and I don’t necessarily determine valid pre/post conditions. I mean correct in as much as, it works for what I need it to work for.

For small programs, this is pretty easy. When you get to larger systems, this becomes a slightly different problem to solve. In the days of goto, spaghetti code arose due to poor organization and ad hoc control transfer. Structured programming helped some by organizing the control codes into a set of well-defined idioms. Object oriented programming helped further by organizing responsibility into encapsulated modules. All of these paradigms had something in common; you could write brittle code or malleable code in any one of them. Granted, writing flexible code has gotten easier with Object Oriented programming, but only if you know what makes code brittle.

Over dependence of one section of code on another section of code. In software engineering, we call this coupling. If the behavior of A is dependent on the behavior of B, then A is dependent on B. Changing the behavior of B could change the behavior of A. This isn’t always a bad thing, but if A and B are written by different people (or the same person at different times) with different goals, it could be catastrophic. It isn’t always feasible to decouple two classes, or two methods, or even two lines of code, but if you can do it easily, consider what might be gained by that.

One syndrome I’ve noticed is that with any concept, some people take it to the extreme. For those readers who stopped at the above paragraph and decided I was right, and everything should be as decoupled as possible, you might see a design that I would call disintegrated. It is possible to create code that is so decoupled as to be impossible to figure out how one thing affects another, even though the overall system is design for A to affect B. Don’t do this

One approach to decoupling two classes is to have them communicate through an event system. This will couple them both to the event system, but not to eachother. This approach allows you to replace one of the pair without changing the other side at all. This makes a lot of sense for GUI applications, for example, where user interactions with the component (such as a button) generates an event that can be handled very differently, depending on the needs of the program. Most object oriented languages, and Java in particular, already has a useful mechanism for invoking behavior on other objects. Its called method invocation, the act of making a method call. Event systems are useful for decoupling the method call from the class that needs to know about the call, its not so useful as a replacement for normal method invocation.

There are plenty of other ways to decouple you code (often through use of patterns), but I won’t get into them here. GIYF

Software design is about making difficult choices. If you didn’t have to make choices, then it would be easy to create a simple program that can design software. Your job as an engineer is to decide what should be decoupled from what. Decoupling can be a great tool to create a reusable component, but not everything should be designed to be reusable. If you’ve written something that was coupled, but needs to be made reusable… Well, thats what refactoring is for. Decoupling two classes that only communicate with each other can actually add complexity for that use case, so unless you strongly believe that at least one of the two classes will be useful in other situations, it is a waste of cognitive power to separate them.

My goal for production-quality software design? Create the simplest design that meets all my requirements, but is flexible enough to adapt to future requirements.

Let’s say that I have a value that represents an angle. I could use a double to represent the radians, or I could create a class called Angle, which internally might use a double to represent radians. If you are trying to avoid primitive obsession, you would use the latter. Now you have value objects of type Angle which can be used in meaningful ways. So, we’re done, right? I say no.

Angle is now its own form of primitive. Just as an Integer object is an abstraction of a numeric value in a specific set of reals, an Angle instance is an abstraction of a geometric/trigonometric angle. This means that it can be the building block for other more specific types. For instance, a 2 dimensional vector can be represented in “polar form” as an Angle and a Magnitude. In a physical simulation, a Magnitude is often a Distance, so we’ll assume that case for this article.

So, we can create a Vector interface (not to be confused with the java.util.Vector class). We can then create a PolarVectorImpl class which uses Angle and Distance. We can even create a CartesianVectorImpl which uses two Distance objects to represent the vector. Whats more, is these can both be used by anything that expects a Vector, with no extra work in the client code. We can easily create a rotate(Angle) method, or any other useful methods.

Another important and related concept that we haven’t touched on is mutability. If an object is mutable, that means that the apparent state of the object can change over the lifetime of the object. If an object is immutable, the apparent state of the object will appear the same throughout the lifetime of the object. This means that any invocation of one method on that object will always have the same outcome as any other on that same method. Also, any object that is returned from those methods must either be immutable themselves, or be distinct instances. Why is this important? Immutable objects have some benefits.

• Immutable objects are inherently thread safe.
• Immutable objects are easy to reason about.
• Immutable objects are easier to debug.
• Immutable objects can be passed around freely without defensive copying.

On the down side, immutability makes a pretty boring universe. If you’re object is expected to do different things depending on what has happened to it in the past, that object must be mutable. It must have state.

What does this have to do with primitive values? Its common to create immutable value objects. If we design the Angle class to be immutable, then we can safely say that one instance represents exactly one angle throughout its lifetime. All of our Angle objects are value objects. They are utility objects and reusable in many projects. On the other hand, if we’re doing a simulation of sorts, it might be useful to have a mutable angle, something that we can adjust over time. Lets call this class Heading. What’s in a Heading? An Angle, of course. Now here’s where things get interesting…

Since an Angle is a measurable thing, its easy to compare two values for equality. For Angles specifically, they are equal if their values represent the same geometric angle. Once equality is established, those objects are equal for ever. Not so with Heading. A Heading may represent the same angle at one moment in time, but at another moment they represent very different angles. For this type of object, equality only makes sense for the identity. A Heading instance is its own object, and can be queried/manipulated by many other objects/methods within the project.

The benefit of this design, is a manipulator/querier need not know who “owns” the Heading instance. A Robot might have a Heading, and a SteeringServo might manipulate that Heading. You can create the Robot and the SteeringServo objects independently of each other. The SteeringServo doesn’t even need to know its the Heading of a Robot. Once the Robot and SteeringServo both have the same Heading instance, they become connected without being coupled. This is huge goal for Object Oriented designers/programmers. The correct functioning of a SteeringServo isn’t dependent on the correct functioning of a Robot, or even of a Heading, only on itself. Similarly, a Robot’s correct functioning isn’t dependent on the correct functioning of the SteeringServo. The program as a whole may not work if there is a bug, but it easier to look at one class and ask yourself “Is there anything wrong with this code,” than it is to ask the same question about the whole project.

If you think all of this abstraction is unnecessary or unhelpful, think about all the layers beneath our Heading class. Lets have some fun and break it down into its most primitive parts.

• Heading instance is an identity value containing an Angle and representing a direction at a point in time.
• An Angle is an equal-comparable value containing a double and representing a direction.
• A double is a equal-comparable and order-comparable value containing an ordered set of bits and representing a real number.
• A bit is an equal-comparable value containing a memory cell representing true or false.
• A memory cell is often times a capacitor that is either charged or uncharged

If you had to think about the implementation details of a bit every time you used a double, it would make the mental weight of programming so immense that no useful programs could be written. Heading can now be used very easily without adding the mental weight of how its implemented. SteeringServo can be implemented without the mental weight of what it is steering. Overall, the practice of this kind of decoupling will make your program easier for the most important source-code interpreter. You.

To put things in perspective, let me list some examples of well designed projects that use reflection.

JUnit

JUnit uses reflection to ease the creating of individual tests. A test writer can add a test simple by creating a public void method with a name that starts with “test”. This allows you to write many distinct tests without having to “wire up” the tests manually. They get executed by virtue of naming convention.

The Spring Framework

The Spring Framework is actually a collection of many different “tools”. Its guiding principal is to help software engineer better design thier systems to use the Inversion of Control pattern. There are many different parts of Spring that use reflection to aid with IoC, so I’ll just name one example. Spring allows you to define an application context in XML. The application context allows you to inject dependencies, so that class implementations don’t have to care about where their dependencies come from. Its almost obvious that reflection is the cleanest way to handle any java object in abstract ways. Without reflection, you would have to litter your code with Spring specific interfaces and implementation details. Ick!

Hibernate

Hibernate is used to map data between object models and relational models. In other words, its used as the bridge between Java and SQL. The latest versions of Hibernate allow you to create your database structure based on your JavaBean classes. It uses reflection (and proxies) to automate translation to and from relational data.

There are a few more well-designed projects that use reflection, but lets look at what seems to be a common thread.
JUnit is a general-purpose testing framework. Spring is a general-purpose IoC framework. Hibernate is a general-purpose ORM framework.

See a pattern?
Reflection is well suited for general purpose frameworks. Its used when polymorphism just won’t cut the bill.

So, what abuses of reflection have I seen? I have to admit, and I’m ashamed, they are mostly ones I’ve committed.
—-
One of the more “interesting” classes I’ve created is the DelegateMap. The DelegateMap implements java.util.Map, and allows you to “connect” a bean object to it. This means the map becomes a view of the bean. if you call map.put(”propertyName”, value), it will actually update the bean. if you call map.get(”propertyName”), it will return the value held by the bean’s property. Sound like a useful gizmo? I won’t say it isn’t useful, but it is a bit more error prone than I would have liked.

map.putAll(otherMap) is an interesting use of this class. At first glance, it looks like you can copy one bean to another, without worrying about individual properties. assert !book.getCover().judged(); An interesting note about the JavaBean spec, is that by default, all objects have a property called “class” {see Object.getClass()}. This property is read-only (imagine trying to implement strong-typing in an environment where the type can change at will!). delegateMap.putAll(otherDelegateMap) will throw an exception when it tries to set the read-only property “class”.

The other danger of this class is that it breaks refactoring. Simple automatic refactoring, such as IntelliJ IDEA’s “rename”, should change the source of a project without changing the behavior. If you have two objects that aren’t related other than through naming convention on the property name, it becomes conceivable to break a “delegate map copy operation” simply by changing the name of one property in either class. Whats worse is your compiler will not notice, and your tests may not warn you in time.
—-
I’ve found myself refactoring away from introspection and reflection time after time. Inversion of Control is my usual destination pattern. Using polymorphism over reflection, I find that my design is cleaner and my code more easily understood. I also find that I have far fewer exceptions in my log files.

If I may make an analogy, reflection is a high-temperature cutting-torch, and we usually just need to cut some paper. Use with caution, and wear some safety goggles.