Java Keywords (Part III): Returning Values from Methods

I have covered 7 keywords so far in the "Java Keyword" series, plus the eight primitive data types in my "Data Types" blog. In this article, I will discuss the keywords return and void. But, in order to understand their usage, I must get into a bit deeper discussion of some fundamentals of computing.

Java keyword list

abstract continue for new switch
assert default goto* package synchronized
boolean do if private this
break double implements protected throw
byte else import public throws
case enum instanceof return transient
catch extends int short try
char final interface static void
class finally long strictfp volatile
const* float native super while
Keyword marked with an asterisk (*) are keywords that, although valid, are not used by programmers.
Although the list above is arranged in alphabetical order, I will go through them in a different order.

Method return values

return and void

It makes sense to discuss these two keywords together. They are almost symbiotic in nature. In a method definition, void indicates no value will be returned to the caller of the method, while return "returns" from the method. Let us review method declaration for just a moment. 

public class Coin
{
    private final double value;

    // Constructor and other members omitted

    // returns a value
    public double getValue()
    {
        return value; // returns the value stored in the "value" data member
    }

    // returns no value
    public void printValue()
    {
        System.out.println((int)(value * 100) + " cents");
    }
}

In the method signature, the parameter located just before the method name is the return type. In the code above you can see that the getValue() method returns the value of the Coin object. This value is of type double. This is important because the entity calling this method must know what type of data it is receiving (if any) in order for it to know how to process it. This is how invoking this method will look on the client's side (assume the Coin object instance was property constructed): 


double value = myCoin.getValue();

The data type of the entity to the left of the equals sign must match the return type of the method being invoked on the right side of the sign. In this example, the method getValue() returns a primitive double and the variable on the client's side is also a primitive getValue().

What about void? I mentioned before that void returns no value which is different than saying "returns nothing". It was worded like that for a very good reason. All methods return something. If you have taken an introductory class in computer science or have taken Assembly Language, you should know that all functions (methods) return the address of the next instruction stored in stack. 


public class HelloWorld
{
    public static void main(String[] args)
    {
        System.out.println("Hello World!");
        System.out.println("Java is fun!");
    }
}

Without going in a lot of details, when a program is executed, the address of the first instruction is loaded into memory. As each line of code is executed, the address of the next instruction is loaded so the program knows what to do next. Here you can see two instructions inside the main method. But, what it may not be immediately obvious is that those instructions are calling methods belonging to another class that is loaded in another area of memory. In this example, when System.out.println("Hello World!") is called, the address of the next instruction (System.out.println("Java is fun!")) is stored in something called the "Instruction Pointer". This instruction is stored in stack. As the name implies, a stack is a data structure where the first item you store in it is the last item that you take out (like a stack of pancakes!). Once the address of the next instruction is stored in stack, the call to the println() method is made, the instruction pointer receives the address of the first instruction inside the println() and the process continues. Each time a line is executed, the Instruction Pointer is updated with the address of the next instruction. When the last instruction is executed, the stack is popped so that the address that was stored before the initial call is once again set in the Instruction Pointer. In our example, this is the address of the System.out.println("Java is fun!") instruction.

In short, when a method returns void the method might not return a value to the client who called it, but the Operating System must return the address of the next instruction to the Instruction Pointer that was previously stored in stack. Lastly, you might have noticed that a method returning void does not have an explicit return line. In Java, it is not necessary to include a return at the end of the method.

Comments

Post a Comment

Popular posts from this blog

Combining State and Singleton Patterns to Create a State-Machine

Image
In my previous two posts, I discussed real-world applications for the Singleton and State design patterns. In this article, I am going to illustrate how to combine both of these patterns to create a simple wizard. Simple State Design Pattern Implementation In a typical implementation of the design pattern, State is either an interface or abstract class, with each state of the state machine being Singleton classes. My example is going to be slightly different. I will implement the state machine using a state interface and Java enums to implement the Singleton. Using an enum is the recommended way to implement a Singleton in Java. First, let's come up with a simple state interface State.java public interface State { void goNext(Context input); void goPrevious(Context input); } Now that we have an interface defined, we can derive as many states as we need. For this example, three states should be sufficient to demonstrate the wizard's functionality. Jav
Read more

Exception Handling: File CRUD Operations Example

Image
Introduction to Exception Handling This is a supplement to my previous blog Creating Custom Exception Classes in Java . I recommend you read that one first and then read this one. Java provides many Exception (and Error) Handling classes. Both of these categories implement the Throwable interface. Although it is not imperative that you develop your own custom exception classes, it is often a good idea to do so; particularly when dealing with large systems. The main reason to create custom exception classes is to quickly identify which custom class is being affected or causing these custom exceptions. For example, referencing a null object and trying to use it will result in a NullPointerException . However, in your code, there could be literally hundreds or even thousands of statements which could result in such exception. Designing your Custom Exception Class Suppose that you are designing a class that will serve as a message receiver. For simplicity,
Read more

The Beauty of the Null Object Pattern

Image
Before we start... Let me start by saying this: NEVER dismiss an idea without giving it any consideration. That was the mistake I made when I first encountered an article about this design pattern many years ago. I was thrown off by the name and without even attempting to find out what this design pattern was all about, I moved on to other things. That was a huge mistake and I am not afraid to admit it. I urge you not to make that mistake. And if you have already, never make that mistake again. Trust me, you will thank me later. For now, let me tell you my story and attempt to explain when to use it along with a simple example on how to implement this pattern. The Null Object Pattern By definition, the main purpose of this pattern is to have an Object-Oriented alternative to the absence of objects by creating objects that display "do nothing" behavior. That sounds like a mouthful. In simplest terms, it is meant to provide a mechanism to replace null references w
Read more