Programming Java: When Errors Occur
Errors in Java applications can occur at various times. However, you can broadly classify when an error will occur into two categories, at compile time and runtime, as described in the following sections.
Compile time errors
The compiler converts your application code into Java byte code. During this process, it takes the human-readable code that you write and converts it into something that the Java Runtime Environment (JRE) understands.
To perform this process, the compiler must parse the code, which means it reads the code in a manner that unambiguously determines precisely what you want the application to do, when you want it to do it, and how you want the task accomplished. If you break the rules for writing unambiguous code, the compiler displays an error message. This message is actually a kind of exception.
Parsing means to read the input you provide, such as code in human-readable form, and turn it into something else, such as Java byte code. An application can also parse user input. For example, a user could type a string that your application code turns into a number.
So, parsing is the act of reading some type of input, interpreting that input in a specific way, and then producing output based on the interpreted input. A parser generates an error when the input isn’t what it expects.
For example, if the user inputs a string containing the letter C, and you expected a string containing a number, such as 123, the parser will generate an exception saying that the input is incorrect.
Compile time errors are the easiest to handle because the compiler normally tells you precisely what’s wrong and where the error has occurred. Even if the information isn’t exact, the compiler will at least get you to the right area of the broken code so that you can look for the error it contains.
To ensure that everyone understands precisely how the Java language is supposed to work, developers create a specification for it. This specification includes the language elements in a special language called Backus-Naur Form (BNF). Using BNF is an extremely precise method of describing a language so that there isn’t any risk of misinterpretation by anyone.
You can see a sample of the BNF for the Java language at Department of Computer Science – Daimi. Don’t worry too much about being able to read this specification. Most developers never learn to interpret the BNF for the languages they use — that’s the domain of compiler developers.
The Java compiler can’t find every error in your code. If the form of the code is correct (that is, you haven’t made any mistakes in typing the elements that create the application), the compiler won’t find the error.
For example, if you initialize a numeric value to 5 instead of 4, the compiler can’t find the error for you because the compiler has no idea that you really meant to type 4. These sorts of mistakes create runtime errors — those errors that happen at some point during the application execution.
Runtime errors can occur at all sorts of times. Some errors are more likely to occur at specific times. The following list provides you with some ideas about when runtime errors are likely to occur:
Initialization: When the application first starts — before it presents any sort of interface to the user or performs any useful work — it goes through an initialization phase. This is when setting a variable to the incorrect type or trying to use a variable before you initialize it will get noticed. Many resource-related errors also occur during initialization because most applications open required resources during this time.
Operating mode: After an application initializes, it’s in operating mode. If it has a user interface, it begins interacting with the user. This is the time when user input matters most.
You’ll also find incorrectly initialized variables at this time because the user (or the recipient of the application output, such as the system) will see that the output is incorrect. User requests for resources, such as a data file, also create errors during this time.
Background processing: Most background processing errors result from the environment (such as the loss of a network connection), missing resources (such as a lost file), incorrectly initialized variables, or errors in how you told the application to perform a task. Some tasks are more commonly performed in the background than others are.
For example, printing a document or downloading resources from the Internet are commonly performed in the background, while the user continues to work with the application in the foreground.
Shutdown: When the user (including the system accounts) tells the application it’s no longer needed, the application goes through a shutdown phase. During this shutdown phase, the application closes files and performs other housekeeping chores that ensure the application doesn’t leave a mess for the operating system.
The most common errors that can occur during this phase are not releasing resources that your application has used and not saving data to disk. Of course, coding errors can occur at any time, and this phase of operation is no exception. You could tell the application to close five files when only four of them are actually open.
The JRE will present most runtime errors it detects to you as exceptions. However, the JRE won’t catch every error in your application. You must also look at the output of your application to determine whether the output matches the expectations you have for a given input.
Additionally, it’s important to look at the state of any resources you use to ensure that they’re not damaged in some way. For example, you need to ensure that any data you should save in a file actually ends up in the file when your application shuts down.
Java 8 has a stronger emphasis on security, which means that you’ll see more SecurityException instances as you work with your application.
Seeing an increase in security exceptions doesn’t mean your code is faulty or that Java 8 is filled with bugs — it means that Java 8 automatically locates and tells you about issues that could cause security problems as people use your application.
The SecurityException documentation appears at Java.net. Of course, you’ll want to know what all the hubbub is about.