Programming Java: Throwing Errors
It’s essential that your Java code makes every effort to fix a problem. However, there are times when your code simply doesn’t have enough information, resources, rights, or some other requirement to fix a problem.
When this happens, your code throws an error by using an exception object. The term exception is appropriate because it should be the exception to the rule, rather than the first act that the application performs. Even so, applications encounter errors that require exceptional measures, and the following sections describe how to deal with these sorts of situations.
Throwing errors during exceptional conditions
For practice, you can create an application that can generate multiple kinds of errors. Normally, you wouldn’t throw an error if a value is in the wrong range — you’d display a message directly to the user instead. However, you can create an example that demonstrates how to throw and catch an error from within a method.
Passing errors to the caller
Many code examples you begin with are just starting to get to the point where you’re calling methods from main(). The main() method is always the top level of your application. As you call methods, the methods that you call form additional levels.
For example, a method called from main() would be at the second level of your application. If that method had to call another method, that method would be at the third level, and so on. Most applications are made up of many levels of calls.
In fact, when you see an exception onscreen, it actually displays a list of the methods that called the current method in a format called the call stack.
The call stack is a listing of methods and the order in which they are called by other methods. Knowing the call stack can help you locate the source of a potential error when it doesn’t happen at the current level of the application.
Handling errors is an essential part of good programming practice. If you want robust applications that don’t constantly crash, you need to provide good error handling. However, trying to handle an error when you don’t have enough information to handle that error is also a problem.
When your code attempts to fix an error at too low a level, it hides the error from a level that could possibly fix it. Yes, you want to fix an error at the lowest possible level, but not at the expense of providing a repair that could actually end up hiding something more serious.
When you find that a particular level of an application doesn’t have the required resources, information, privileges, user access, or some other item needed to handle an error, then you issue a throw statement with the appropriate exception object. The previous level of the application will receive the exception and determine whether it can handle it.
However, if the main() method receives the exception, then you must determine what to do with the error, or the application will crash. It’s generally considered bad programming practice to simply let the application crash — you need to come up with some way to deal with errors that the application encounters.
Required error handling
Java provides two kinds of exceptions: checked (those monitored by the JRE) and unchecked (those that aren’t monitored by the JRE). You have the option of handling an unchecked exception. However, Java forces you to handle a checked exception. Your code won’t even compile if you try to use a method that has a checked exception associated with it.
A checked exception is one that the JRE is told by the class definition to monitor. The JRE forces the user of the class to provide handling for the exception to ensure that the class performs reliably.
All kinds of odd details are associated with checked and unchecked exceptions. An easy way to know whether an exception is checked is to know the parent class. All exceptions that are subclassed from the Error or RuntimeException classes are unchecked — every other exception is checked.
The best practice is to handle every exception in your application, and you won’t have to worry whether an exception is checked or unchecked. A great developer always handles potential errors — that’s the bottom line.