Coding Zen: Sticking to the fundamentals

Because my Eclipse project didn't print the exception,
I set a breakpoint and stepped into the problem to find
something resembling a stack trace.

In my previous post, I described the 'bane of Java programmers,' the ClassNotFoundException. I also outlined its most basic causes, and gave a brief outline of my case.

This post, however, will cover the longer story of my debugging. The intent is to show that debugging can often be a tricky process, and that it's very important to rule out all of the basics first. I knew the projects own files were not somehow improperly imported into the project, and my classpath files all seemed right, which led me (to my downfall) to assume that the problem must be very complex.

I decided also to build upon the previous Coding Zen lesson with a new one, which we will find is tantamount to finding the solution in the more exceptional debugging cases:

The amateur studies advanced techniques; the master practices the fundamentals.

Coding Zen: Debugging by understanding

The wise programmer does not seek to find the solution, but to understand the problem.

It's been two months today, since I initialized Blog codeCrave = new Blog();, and since then I've encountered a number of interesting problems with my code. Many of them I've omitted posting about, because of the lovely tool known as Stack Exchange, and its more-commonly-used Stack Overflow. This lovely site has (very appropriately) datified the many problems one might encounter when working on making a computer or web application of any kind.

Shamelessly borrowed from Java EE Support Patterns blog

But in many ways, it serves to weaken the mind. By delegating our problem-solving skills to the crowd-sourced Stack*, we risk denying ourselves adequate development of our own problem-solving skills.

Consider the ClassNotFoundException that is often called the "bane of Java programmers," so much so that there's an entire web service dedicated to helping you debug a ClassNotFoundException. Does that seem excessive?

It's not. Because this problem can be a doozie.

Mindful of the above heuristic, I'm going to walk through the ClassNotFoundException: what it is, what can cause it, and how to solve it. I will go through my particular solution.

The Diamond Problem: C++

When you allow for inheritance of multiple parents in a programming language, you get a whole slew of messy issues that you don't have to deal with when programming in more simplified languages like Java. Simplified languages take care of a lot of background details for the programmer (a trait that has its own tradeoffs).

How many eyes would Bee have?

Let's say you have three levels of classes: Animal, Winged and Legged, and then Bee. As you might know, bees have both wings and legs, which means that, in C++, your Bee class would inherit from both Winged and Legged. Do you see the problem?

Both of those classes inherit from Animal! In your memory allocation, should C++ store room for two instances of Animal's variables, or just one? This is called the "Diamond Problem."

Making bite-size issues to tackle

This issue may prove to be divisive, but it seems worth discussing from the viewpoint of a newblood programmer and a potential employer alike.

When using GitHub "Issues," there are two common uses: public users viewing the repository can submit bugs, problems, or desired features, as general or specific as they'd like; the other use is for repo owners to give tasks to one another. This post focuses on how best to utilize the latter for maximum productivity, in a way that still gets work done.

The trick is to make your issues as bite-size and manageable as possible.