Java Exception Handling

Java Exception Handling – AbstractMethodError

Moving along through our in-depth Java Exception Handling series, today we’ll be going over the AbstractMethodError. This error is thrown when there are incompatibilities between compiled classes/JAR files using abstract methods.

Throughout this article we’ll examine the AbstractMethodError by looking at where it fits into the overall Java Exception Hierarchy. We’ll also dig into a functional code example that illustrates the basics of using abstract classes and methods in Java, and how their use may lead to AbstractMethodErrors in your own code. Let’s get to it!

The Technical Rundown

All Java errors implement the java.lang.Throwable interface, or are extended from another inherited class therein. The full exception hierarchy of this error is:

Full Code Sample

Below is the full code sample we’ll be using in this article. It can be copied and pasted if you’d like to play with the code yourself and see how everything works.

This code sample also uses the Logging utility class, the source of which can be found here on GitHub.

When Should You Use It?

In most situations you’ll rarely experience AbstractMethodErrors during runtime, because they are typically caught by the compiler prior to execution. However, there are certain scenarios in which code is referencing outdated abstract classes, which can lead to AbstractMethodErrors. Most commonly, consider a situation where an abstract class and an inherited class are compiled. Next, modifications are made to the abstract class and only that abstract class is recompiled, while the extended class is left alone. This can cause AbstractMethodErrors, since the runtime doesn’t know how to handle the incompatibility between the two classes.

To illustrate we’ve created a basic Publication abstract class, which defines a handful of methods that should be implemented in all extension classes:

The AbstractBook class then extends Publication and provides actual implementation of the abstract methods above:

We can test this out by creating a new AbstractBook instance and outputting it to the log:

Executing the createBookTestA() method produces the following output:

That’s all well and good, but what happens if we modify one of these classes but not the other (effectively causing their versions to be incompatible)? For example, let’s modify the Publication abstract class and add another abstract method:

If we compile just this Publication class, but not also the inherited AbstractBook class, executing our test code will result in an AbstractMethodError, since the secondary class hasn’t been recompiled and made aware of the changes:

The Airbrake-Java library provides real-time error monitoring and automatic exception reporting for all your Java-based projects. Tight integration with Airbrake’s state of the art web dashboard ensures that Airbrake-Java gives you round-the-clock status updates on your application’s health and error rates. Airbrake-Java easily integrates with all the latest Java frameworks and platforms like Spring, Maven, log4j, Struts, Kotlin, Grails, Groovy, and many more. Plus, Airbrake-Java allows you to easily customize exception parameters and gives you full, configurable filter capabilities so you only gather the errors that matter most.

Check out all the amazing features Airbrake-Java has to offer and see for yourself why so many of the world’s best engineering teams are using Airbrake to revolutionize their exception handling practices!