{"title":"Return Types","description":"","content":"Methods are how programs split work into named pieces. Some pieces do something and have nothing to hand back. Others compute a value, a price, a flag, a list of items, and the caller needs that value to keep going. The return type is the contract the method makes with its callers about what comes out the other end. This lesson covers `void`, primitive returns, reference returns, the `return` statement itself, early returns, and the small pile of compiler rules that govern all of it.\n\n---\n\n# What a Return Type Declares\n\nThe return type sits between the modifier list and the method name in the header. It tells the compiler, and anyone reading the code, what kind of value the method produces. The body is then required to honor that promise.\n\n\n```java\npublic class ReturnTypeBasics {\n public static void main(String[] args) {\n double price = getPrice();\n System.out.println(\"Price: $\" + price);\n }\n\n static double getPrice() {\n return 29.99;\n }\n}\n```\n\n\nThe header `static double getPrice()` says two things. First, calling this method gives you back a `double`. Second, anyone calling it can use that `double` directly in an expression, assign it to a variable, or ignore it.\n\nEvery method declares exactly one return type. There's no syntax for returning two values at once. If you need to return more than one piece of information, you wrap them in an array, a `List`, or a small class. Java also doesn't let two methods in the same class differ only by return type; that part falls under method overloading.\n\n\n```mermaid\nflowchart LR\n Caller[Caller
double total = getTotal()]:::cyan --> Call[Method call]:::orange\n Call --> Body[Method body executes]:::orange\n Body --> Ret[return value]:::green\n Ret --> Capture[Value handed back
assigned or used]:::cyan\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe diagram traces one call. The caller invokes the method, the body runs, a `return` statement produces a value, and that value flows back to where the call was written. From the caller's point of view, the whole method call is replaced by its return value.\n\n---\n\n# `void`: Methods That Don't Return Anything\n\nWhen a method's job is to do something rather than compute something, its return type is `void`. The keyword means \"no value comes back\". Printing, updating, sending, logging, all natural fits.\n\n\n```java\npublic class PrintReceipt {\n public static void main(String[] args) {\n printWelcomeMessage(\"Alice\");\n }\n\n static void printWelcomeMessage(String customerName) {\n System.out.println(\"Welcome back, \" + customerName + \"!\");\n System.out.println(\"Your cart is ready.\");\n }\n}\n```\n\n\nThe method does its work and falls off the bottom. There's no `return` line, and that's fine. A `void` method is allowed to omit `return` entirely. It can also use a bare `return;` to exit early.\n\nYou cannot assign the result of a `void` call to a variable, because there is no result.\n\n\n```java\nString greeting = printWelcomeMessage(\"Alice\"); // compile error\n```\n\n\nThe compiler says `void cannot be converted to String`, which is its way of pointing out that you tried to capture nothing.\n\n---\n\n# Returning a Primitive\n\nWhen the return type is a primitive (`int`, `long`, `double`, `float`, `boolean`, `char`, `byte`, `short`), the method hands back a value of that exact type, or a value the compiler can widen to that type without losing information.\n\n\n```java\npublic class PrimitiveReturns {\n public static void main(String[] args) {\n int stock = getStockCount();\n double tax = getTaxRate();\n boolean inStock = isInStock(stock);\n\n System.out.println(\"Stock: \" + stock);\n System.out.println(\"Tax rate: \" + tax);\n System.out.println(\"Available: \" + inStock);\n }\n\n static int getStockCount() {\n return 42;\n }\n\n static double getTaxRate() {\n return 0.08;\n }\n\n static boolean isInStock(int count) {\n return count > 0;\n }\n}\n```\n\n\nEach method's return statement produces a value that matches the declared type. `getStockCount` returns an `int` literal, `getTaxRate` returns a `double` literal, and `isInStock` returns the result of a comparison, which is already a `boolean`.\n\nReturning a `boolean` is the standard way to write a yes-or-no method. Names like `isInStock`, `hasDiscount`, or `canShip` read naturally at the call site.\n\n\n```java\npublic class BooleanReturn {\n public static void main(String[] args) {\n double subtotal = 120.0;\n if (qualifiesForFreeShipping(subtotal)) {\n System.out.println(\"Free shipping applied.\");\n } else {\n System.out.println(\"Add more items for free shipping.\");\n }\n }\n\n static boolean qualifiesForFreeShipping(double subtotal) {\n return subtotal >= 100.0;\n }\n}\n```\n\n\nThe method compresses a small piece of business logic into a name the caller can read in an `if`. That's most of the value of returning `boolean`. You move the \"what does it mean\" out of the call site and into the method.\n\n### Implicit Widening on Return\n\nA method that returns `double` can `return` an `int` literal. The compiler widens the `int` to a `double` for you, the same way it widens during assignment.\n\n\n```java\npublic class ImplicitWidening {\n public static void main(String[] args) {\n double shipping = getShippingCost();\n System.out.println(\"Shipping: $\" + shipping);\n }\n\n static double getShippingCost() {\n return 5; // int literal, widened to double\n }\n}\n```\n\n\nThe `5` becomes `5.0` on its way out. The reverse is not allowed. A method that returns `int` cannot `return` a `double` value, because that would lose the fractional part. The compiler refuses unless you cast explicitly.\n\n\n```java\nstatic int getQuantity() {\n return 3.7; // compile error: incompatible types\n}\n```\n\n\nThe fix is either to change the return type to `double` or to cast: `return (int) 3.7;`. The cast truncates to `3`, and the compiler stops complaining because you've taken responsibility for the loss.\n\nWidening is free at the level of generated bytecode for most pairs. The cost comes from accidental widening that masks a bug, like a method declared `double` returning an `int` result that's missing rounding logic.\n\n---\n\n# Returning a Reference Type\n\nReference types include `String`, arrays, and any class you or someone else defined. Returning a reference works the same way as returning a primitive, except the value handed back is a reference to an object rather than the object itself. The caller and the method end up pointing at the same object.\n\n\n```java\npublic class StringReturn {\n public static void main(String[] args) {\n String label = formatPrice(29.99);\n System.out.println(label);\n }\n\n static String formatPrice(double amount) {\n return \"$\" + amount;\n }\n}\n```\n\n\nThe method builds a string and hands the reference back. The caller assigns it to `label`. From here on, both the method's local variable (already gone, since the method returned) and the caller's `label` refer to the same `String` object.\n\nReturning an array works the same way.\n\n\n```java\npublic class ArrayReturn {\n public static void main(String[] args) {\n int[] prices = getTopThreePrices();\n for (int p : prices) {\n System.out.println(\"Price: $\" + p);\n }\n }\n\n static int[] getTopThreePrices() {\n return new int[] { 99, 199, 299 };\n }\n}\n```\n\n\nThe method allocates a new array and returns the reference. The caller treats the array as its own. Whether changes the caller makes to the array are visible back inside the method depends on what the method does after returning, which is usually nothing, since it's already finished.\n\nA method can also return objects of types you define. Consider a `Product` class that holds a name and price.\n\n\n```java\nclass Product {\n String name;\n double price;\n\n Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n\npublic class ObjectReturn {\n public static void main(String[] args) {\n Product p = findProductById(101);\n System.out.println(p.name + \" costs $\" + p.price);\n }\n\n static Product findProductById(int id) {\n return new Product(\"Wireless Mouse\", 29.99);\n }\n}\n```\n\n\nThe method builds a `Product` and returns the reference. The caller reads fields off it. Returning custom objects is how methods communicate richer pieces of information without resorting to arrays or parallel return values.\n\n---\n\n# The `return` Statement\n\n`return` does two things at once. It produces a value (unless the method is `void`) and it exits the method immediately. Once a `return` runs, control leaves the method and goes back to the caller. Nothing else in the method runs.\n\n\n```java\npublic class ReturnExits {\n public static void main(String[] args) {\n System.out.println(\"Discount: \" + getDiscount(150.0));\n }\n\n static double getDiscount(double subtotal) {\n System.out.println(\"Calculating discount...\");\n return subtotal * 0.10;\n // anything written here would be unreachable\n }\n}\n```\n\n\nThe `return` line evaluates `subtotal * 0.10`, then leaves the method with that value. If you tried to put a statement after the `return`, the compiler would reject it with an `unreachable statement` error.\n\n\n```java\nstatic double getDiscount(double subtotal) {\n return subtotal * 0.10;\n System.out.println(\"never runs\"); // compile error: unreachable statement\n}\n```\n\n\nThis rule exists because dead code is almost always a bug. The compiler catches it for you instead of letting it ship.\n\nA `void` method uses `return;` with no value to exit early.\n\n\n```java\nstatic void printDiscount(double subtotal) {\n if (subtotal <= 0) {\n return; // bail out, nothing to do\n }\n System.out.println(\"Discount: \" + (subtotal * 0.10));\n}\n```\n\n\nThe bare `return;` is only legal in `void` methods. In a non-`void` method, every `return` must carry a value of the declared type.\n\n---\n\n# Multiple Return Paths\n\nA method can have more than one `return` statement. Each branch of the code can have its own. The only requirement is that every path through the method ends in either a `return` (for non-`void` methods) or falls off the end (for `void` methods).\n\n\n```java\npublic class MultipleReturns {\n public static void main(String[] args) {\n System.out.println(\"Tier for $50: \" + getCustomerTier(50));\n System.out.println(\"Tier for $250: \" + getCustomerTier(250));\n System.out.println(\"Tier for $1500: \" + getCustomerTier(1500));\n }\n\n static String getCustomerTier(double totalSpent) {\n if (totalSpent < 100) {\n return \"Bronze\";\n }\n if (totalSpent < 1000) {\n return \"Silver\";\n }\n return \"Gold\";\n }\n}\n```\n\n\nEach `if` either returns or falls through to the next check. The final `return \"Gold\"` covers everything that didn't match earlier conditions. The compiler walks every possible path and confirms that none of them can finish without returning something.\n\nIf you forget the final return, the compiler complains.\n\n\n```java\nstatic String getCustomerTier(double totalSpent) {\n if (totalSpent < 100) {\n return \"Bronze\";\n }\n if (totalSpent < 1000) {\n return \"Silver\";\n }\n // compile error: missing return statement\n}\n```\n\n\nThe compiler can't prove that one of the `if` branches will always run, because in principle `totalSpent` could be `1000` or higher and slip past both checks. Adding the unconditional `return \"Gold\";` at the end satisfies the rule.\n\n### When All Branches Return\n\nIf every branch of an `if-else` returns, the code after the `if-else` is unreachable, and the compiler will tell you so.\n\n\n```java\nstatic String classify(double total) {\n if (total < 100) {\n return \"small\";\n } else {\n return \"large\";\n }\n System.out.println(\"after\"); // compile error: unreachable statement\n}\n```\n\n\nThis is the same rule as before, just spotted in a different shape. The fix is to delete the unreachable code, or to remove the `else` and let the second `return` sit at the top level.\n\n\n```java\nstatic String classify(double total) {\n if (total < 100) {\n return \"small\";\n }\n return \"large\";\n}\n```\n\n\nBoth forms compile. The second is the standard early-return style we look at next.\n\n---\n\n# Early Return (Guard Clauses)\n\nWhen a method has a few \"give up early\" conditions before the real work starts, returning early from each one keeps the rest of the method flat and readable. Each early `return` is called a guard clause.\n\n\n```java\npublic class GuardClauses {\n public static void main(String[] args) {\n System.out.println(applyCoupon(100.0, \"SAVE10\"));\n System.out.println(applyCoupon(100.0, \"\"));\n System.out.println(applyCoupon(-5.0, \"SAVE10\"));\n }\n\n static double applyCoupon(double subtotal, String coupon) {\n if (subtotal <= 0) {\n return 0.0;\n }\n if (coupon == null || coupon.isEmpty()) {\n return subtotal;\n }\n if (!coupon.equals(\"SAVE10\")) {\n return subtotal;\n }\n return subtotal * 0.90;\n }\n}\n```\n\n\nEach `if` handles one case and returns. By the time you reach the bottom of the method, you know the inputs are valid and the coupon is the one you handle. The alternative without guard clauses pushes the real logic into a deeply indented block.\n\n\n```java\nstatic double applyCouponNested(double subtotal, String coupon) {\n if (subtotal > 0) {\n if (coupon != null && !coupon.isEmpty()) {\n if (coupon.equals(\"SAVE10\")) {\n return subtotal * 0.90;\n } else {\n return subtotal;\n }\n } else {\n return subtotal;\n }\n } else {\n return 0.0;\n }\n}\n```\n\n\nSame behavior, more nesting, harder to follow. The guard-clause version is more readable. The general rule of thumb: handle the failure cases first, with each one ending in `return`, then put the main logic at the end where it has the whole method's width to itself.\n\n---\n\n# Returning `null`\n\nA method that returns a reference type can return `null` to signal \"no value\". `null` is a special reference that doesn't point to any object. It's legal, but it shifts a burden onto the caller: any use of the returned value has to check for `null` first, or risk a `NullPointerException`.\n\n\n```java\npublic class NullReturn {\n public static void main(String[] args) {\n String name = findProductName(101);\n if (name != null) {\n System.out.println(\"Found: \" + name);\n } else {\n System.out.println(\"Product not found.\");\n }\n }\n\n static String findProductName(int id) {\n if (id == 101) {\n return \"Wireless Mouse\";\n }\n return null;\n }\n}\n```\n\n\nThe method returns `\"Wireless Mouse\"` for the known id and `null` for everything else. The caller checks before using the value.\n\nThe catch is what happens when the caller forgets the check.\n\n\n```java\nString name = findProductName(999);\nSystem.out.println(name.length()); // NullPointerException\n```\n\n\nThe method returns `null`, the caller calls `.length()` on `null`, and the program crashes at runtime. There's nothing wrong with the compile-time types. The compiler can't tell which calls might return `null`. So in any code that returns `null`, the contract has to be clear enough that callers know to check.\n\nThree common alternatives to returning `null`:\n\n- Return an empty collection or array when the result is \"no items\". An empty list is safe to iterate over without a `null` check.\n- Throw an exception when \"not found\" is a real error worth stopping for.\n- Return an `Optional` (added in Java 8), which is a wrapper that makes the \"no value\" possibility part of the type itself.\n\nReturning `null` is common, but it's the option that puts the most pressure on the caller to remember a check. If you can avoid it, prefer one of the alternatives.\n\n`null` itself is free. The real cost is one missed check turning into a `NullPointerException` in production. Empty collections, sentinel objects, or `Optional` push that check into the type system where the compiler can help you.\n\n---\n\n# Capturing the Return Value\n\nWhen a method returns something, the caller decides what to do with it. There are three options.\n\n**1. Assign it to a variable.** The most common option. The variable's type has to accept the return type.\n\n\n```java\npublic class CaptureToVariable {\n public static void main(String[] args) {\n double total = calculateTotal(29.99, 3);\n System.out.println(\"Total: $\" + total);\n }\n\n static double calculateTotal(double price, int quantity) {\n return price * quantity;\n }\n}\n```\n\n\n**2. Use it directly in a larger expression.** The call's result is plugged in where the call sits.\n\n\n```java\npublic class UseInExpression {\n public static void main(String[] args) {\n System.out.println(\"Total: $\" + calculateTotal(29.99, 3));\n if (calculateTotal(29.99, 3) > 50) {\n System.out.println(\"Free shipping!\");\n }\n }\n\n static double calculateTotal(double price, int quantity) {\n return price * quantity;\n }\n}\n```\n\n\nThe method is called twice here. Each call computes the value independently. If the computation is expensive, assign it to a variable once and reuse the variable instead of calling repeatedly.\n\n**3. Ignore it.** Java lets you discard a non-`void` return value. The expression statement runs, the value is computed, then the value is thrown away.\n\n\n```java\npublic class IgnoreReturn {\n public static void main(String[] args) {\n addToCart(\"Mouse\"); // returns an int, ignored\n System.out.println(\"Item added.\");\n }\n\n static int addToCart(String item) {\n System.out.println(\"Added: \" + item);\n return 1; // number of items added\n }\n}\n```\n\n\nIgnoring a return value compiles, but it's often a smell. Two reasons. First, if the method bothered to return a value, the caller probably should care about it. Second, methods that return a value to signal success or failure are dangerous to ignore. The classic case is `List.remove(Object)`, which returns `true` if the item was removed and `false` if it wasn't there. Ignoring the result means you can't tell whether the operation did anything.\n\nThe exception is methods whose return value is optional. `StringBuilder.append` returns the same `StringBuilder` so callers can chain calls, but the return value isn't new information. Ignoring it is fine when you're not chaining.\n\n---\n\n# Putting It Together\n\nThe next program uses every kind of return type covered above: `void`, a primitive, a `String`, and an object. It walks through a small order flow.\n\n\n```java\nclass CartItem {\n String name;\n double price;\n int quantity;\n\n CartItem(String name, double price, int quantity) {\n this.name = name;\n this.price = price;\n this.quantity = quantity;\n }\n}\n\npublic class OrderFlow {\n public static void main(String[] args) {\n CartItem item = createItem(\"Wireless Mouse\", 29.99, 2);\n double total = calculateLineTotal(item);\n boolean qualifiesForDiscount = total >= 50.0;\n String label = formatLabel(item, total);\n\n printSummary(label, qualifiesForDiscount);\n }\n\n static CartItem createItem(String name, double price, int quantity) {\n return new CartItem(name, price, quantity);\n }\n\n static double calculateLineTotal(CartItem item) {\n return item.price * item.quantity;\n }\n\n static String formatLabel(CartItem item, double total) {\n return item.name + \" x \" + item.quantity + \" = $\" + total;\n }\n\n static void printSummary(String label, boolean discountApplies) {\n System.out.println(label);\n if (discountApplies) {\n System.out.println(\"Discount applied.\");\n return;\n }\n System.out.println(\"No discount.\");\n }\n}\n```\n\n\nFive methods, five different return shapes. `createItem` returns a custom object. `calculateLineTotal` returns a `double`. `formatLabel` returns a `String`. `printSummary` returns `void` and uses an early `return;` to skip the \"No discount\" branch. The `main` method captures and chains the results.\n\nReading the flow top to bottom, each method does one thing and hands back what the next step needs. Good methods settle into this shape: clear inputs, one well-named return.\n\n---\n\n# How Return Types Connect to Each Other\n\nThe table below collects the rules we've worked through, so you have one place to look when something doesn't compile.\n\n\n| Situation | Rule |\n| --------- | ---- |\n| Return type is `void` | No `return value;`. `return;` is allowed for early exit. Can also fall off the end. |\n| Return type is a primitive | Every `return` must produce that exact type, or a narrower type the compiler can widen. |\n| Return type is a reference | Every `return` produces a value of that type, a subtype, or `null`. |\n| Two methods differ only by return type | Not allowed in the same class. Method overloading needs different parameter lists. |\n| Code after `return` | Compile error: unreachable statement. |\n| Some branches don't return | Compile error in non-`void` methods: missing return statement. |\n| Returning `null` | Legal for any reference type. Callers must check or risk `NullPointerException`. |\n| Ignoring a non-`void` return | Legal. Often a smell. Read the method's contract before doing it. |\n","pageType":"java"}

Return Types

Get Premium