Java expects return value when RuntimeException is thrown

The java compiler does not know that the throwIAE will always throw an exception so it assumes that you will eventually reach the end of the run method and, when that happens, a return value is required.

Your method has a return type so it should return a boolean result.

   public boolean run() {
     throwIAE();
     // Missing return statement
     return false;
   }

Or you should throw your exception directly in method :

   public boolean run() {
     throw new IllegalStateException("error"); // it will compile
   }

Even if compilers are smart nowadays, they cannot 'see' that your throwIAE() method always returns an Exception because this will happen during runtime and not compile time. What if you handle the exception? Then you must add a return value eventually.

I didn't really expect this to work, but interestingly you CAN do this, which makes the code a little more readable:

    public static <T> T unsupported()
    {
        throw new UnsupportedOperationException();
    }

     ...
    
    return unsupported();

The exception thrown terminates the throwIAE method, but not the method which calls this one. Understand this as a method returning an output (empty return; since void).

public void throwIAE() {
     return;                // is not responsible for terminating run()
}

Do you see? The return terminates the throwIAE method and the program continues. Both the return and throw is related to the scope of the method itself, not the calling method. You need:

public boolean run() {
     throwIAE();            // throws exception and terminates throwIAR()
     return false;          // terminates run()
}

Good answers so far. I wonder how nobody mentioned AOP(Aspect Oriented Programming). With AOP you can easily intercept your method throwIAE() during RUNTIME and catch the exception. The calling method run() cannot know this.

Some example:

package yourPackage;

public class YourClass {

    public boolean run() {
        throwIAE();
        System.out.println("Hello world!");// prints Hello World! even if method throws exception
        return false;// does not compile without return statement
    }

    public void throwIAE() {
        throw new IllegalStateException("error");
    }

}

And another Aspect class which intercepts throwIAE() method during runtime:

package yourPackage;

@Aspect
public class ExceptionHandlingAspect {
    @Around("execution(* yourPackage.YourClass.throwIAE())")
    public Object handleException(ProceedingJoinPoint pjp) throws Throwable {
        try {
            return pjp.proceed();
        } catch (Exception e) {
            System.out.println("exception caught");
            return null;
        }
    }
}  

While other answers correctly explain the situation from a user's perspective, it is worth noting, that the "cleverness" of analyzing such flows is not at the discretion of a compiler but precisely defined by the rules of JLS. In particular, §14.21 contains this:

An expression statement can complete normally iff it is reachable.

A method invocation like throwIAE() is an expression statement, and because it is reachable in the example, it can also "complete normally". Because of that, the method body can "complete normally", which according to §8.4.7 is illegal for a method with a non-void return type (which is to say, such methods must return a value on all possible paths).

I other words, JLS defines that all method invocations are treated equally during flow analysis, and there is no such concept as "method-that-always-throws".

Imagine this:

 public class NotReallyACompilerIssue extends CompilerIssue {

   @Override    
   public void throwIAE() {
     // doesn't really throw the IAE!
   }
 }

If your original class compiled without the return statement in run(), the run() method in NotReallyACompilerIssue whould've completed successfully and had no return. Which wouldn't be good, would it?

It is be possible to detect such situation if the class isfinal, or method throwIAE isfinal. It isn't the case though, the compiler (Oracle J8_131 at least) does not make such checks. I imagine this is a very specific case and it wasn't worth the effort.