@tosensei

Despite never mentioning this is the method signature what I get when calling that method is _either_ a Brake object, a special "not-return-value" implementing Throwable that tries to escape the block scope, or nothing. While it's true that i can get a Brake from that method it is also omitting some very pertinent information to the caller.

A more honest/explicit implementation would have a signature like:

public Optional<Brake> brake() throws WallCrashException;

but you rarely see that in the wild and it's never enforced unless you implement an ArchUnit test for it or something.

As for being exceptional, maybe that was what Gosling intended them to be, but nine times out of ten it's just a lazy method of control flow.

And yes sometimes "no result" is valid, which is why Kotlin has "Object?" and Java implemented the Optional<T> band-aid, and Rust has Option and Result types.

But you can still always "overload" the base type with a null in Java.

(2/2)

@tosensei

I do love some pedantic programming arguments on the internet 😅 so here I go:

tbh for me "Java Excepions are not return values" is a lot like "Java is always call by value", both are technically correct in that Exceptions have a separate flow that effectively act like a "return to the closest matching catch block in the call stack with this Throwable", and that Java always sends a primitive or the value of a reference (or null) respectively.

To use your analogy:

Based on the signature of this method a reasonable, but naive assumption is that when I call carObject.brake() I should get a Brake object.

public Brake brake(){

switch (new Random().nextInt(3)){

case 0 -> { return new Brake(); }

case 1 -> { throw new RuntimeException("crashed against wall"); }

case 2 -> { return null; }

}

return null;

}

Expected :Brake

Actual :Exception | null | Brake

(1/2)

@netikras

Since forever in this implicit form.

@AlmondSauce

That is technically correct in that thrown exception aren't return values in Java, though in the sense of f(x) -> y then generally Java 'returns' in the looser sense of the word either the value on it's method signatures, null, or an Exception. My main issue is that besides trivial examples, you can never really trust any Java method signature to actually adhere to what it claims to return unless you dig through the source code.

Depending on whether you consider errors and exceptions to be separate concepts or not I think Go is a good example on how to do this right, where every function which can produce an error must explicitly declare so in it's signature. Still has some issues with nil pointers though.