Java History 101: Once Upon an Oak : Page 4

In Oak 0.2, all exceptions were unchecked, meaning that no throws clause existed. My guess is that checked exceptions were added only after the whole exception hierarchy was already set in wet concrete. I would have preferred a separate branch for checked exceptions, something like:

  public class Throwable { }
  
  /** Serious errors in the virtual machine */
  public class Error extends Throwable { }

  public class CheckedException extends Throwable { }
  public class IOException extends CheckedException { }

  public class UncheckedException extends Throwable { }
  public class NullPointerException extends UncheckedException { }

This way you would avoid catching unchecked exceptions when you catch CheckedException. However, the exception class hierarchy appears to have been developed before the idea of checked vs. unchecked exceptions, so we are stuck with an exception mechanism that will cause headaches for generations to come.

Asynchronous Exceptions (Section 9.4.2)
If your program gets an asynchronous exception, you are dead. A few weeks ago I was looking at a program that was throwing OutOfMemoryError. This hiccup can happen at any time really, which is why it is called an asynchronous exception. Another scenario in which this can happen is with Thread.stop(). As you can imagine, this is inherently dangerous (which is why it is deprecated).

In Oak, life was even more precarious. You could cause an asynchronous exception in another thread using Thread's postException() method. Now that was dangerous! Imagine if other threads could cause asynchronous exceptions at any place in your code!

In order to safeguard your code, you could "protect" it. If you wanted to indicate that you had some critical code, which could not handle asynchronous exceptions, you did the following:

  protect {
    /* critical section goes here */
  }

And code that was quite happy with asynchronous exceptions did the following:

  unprotect {
    /* code that can afford asynchronous exceptions */
  }

A note in the margin said that the default would probably be changed to not allow asynchronous exceptions except in explicitly unprotected sections of code. I'm very glad that this feature was tossed. I cannot imagine how complex the Java programs would have become with it in place.

The End
That's it. The rest of the manual was filled with a Glossary and an Index, which pushed the final page count to 38 pages—probably to satisfy some manager who wanted a manual that wouldn't blow away in the wind when he showed it to the marketing guys on the golf course.

Even though this manual was written way back in 1994, it provided for fascinating reading, even late at night.

Editor's Note: This article first appeared in Dr. Kabutz's The Java(tm) Specialists' Newsletter under the title Once upon an Oak .... To subscribe, send an email to subscribe@javaspecialists.co.za.