Java has the worst kind of union type where every method returns the union of Exception | null | value.

Since when java has unions...?

Or.. Are you referring to the execution flow control concept?

Have you tried c++? It's got even more constructs

There's 2 separate concepts here.

Exception handling isn't really a return type - it's not considered as one in any language I know of. I consider exceptions being thrown a good thing, catching and handling them appropriately is part of good code design.

As for value|null though - yeah, I tend to agree. Java's lack of sensible null handling is by far its weakest point imho.

Take JS:
It can return the value, null, undefined, or literally anything else.

@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.

@netikras

Since forever in this implicit form.

@GNIEN-BILLE

Since you seem to be serious, no it's not correct.

A checked exception needs to be explicitly added to the method signature (or caught).

While non-null is not declarable in current Java (Project Valhalla might change that), a function with a primitive return type will never return null.

Nor will a function with void type.

:-)

But.... if you're going outside the pure Java compiler, there is - thx to the extensibility of Java - a lot of fun stuff to poke around and fuck around.

Error Prone as a compiler plugin with
https://github.com/uber/NullAway for example.

I don't think there is any good error handling in any language. There will always be some unhappy person.... though I like Scala's Either type / Kotlin Arrow ...

If you wanna know what I mean, enter in Google "Go error handling sucks".

You will find a lot of people being pretty annoyed by Go's error handling. Not comparing numbers, but given how some people entirely abuse error handling for the most perverted reasons, I'd guess it's true for any language.

(Go to with exceptions... yeah. I've seen stuff.)

@Lensflare Don't forget NaN.

@GNIEN-BILLE sounds to me like you just have a lacking understanding of what "exceptions" and "nullability" are.

as analogy: yes, you _could_ argue that "crashing your car against a wall" is, in a broader definition of the word, some kind of "braking". but noone would actually ever call it that. instead, it's an _exceptional_ case that should never happen during regular operation, and must be handled accordingly - separate of regular workflow.

and as for null: well - sometimes, the logically correct result of an operation is "no result".

@tosensei regarding your point about exceptions:
Most languages and libraries based on those languages don‘t treat exceptions as really exceptional and never to occur in regular operation. They are just used for error handling, almost similar to other control flows.

Either the name "Exception" is badly chosen, or Exceptions are abused by almost everyone.

I think both is true.

@tosensei Importantly for undefined, there could be a unicorn there. Or a pineapple.

@tosensei you could make a joke that it’s the strength of JS: you could use it to encode a 4-state gender value:
true - male
false - female
null - diverse
undefined - not specified

The sad thing is, if you show it to hardcode JS worshippers, they will unironicly say that it’s a great idea!

@Lensflare don't forget FileNotFound

https://thedailywtf.com/articles/..._

edit: okay, devrant-coders, you got a bug. this link has a trailing `_` - which isn't recognised as link and results in a 404.

fix your shit.

@tosensei FYI: trailing _ bug is present in my custom client as well so it’s either the API or the backend.

@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)

@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)

@GNIEN-BILLE

"I do love some pedantic programming arguments on the internet"

well, if you're not pedantic, then you're a shitty developer.

also your counter-argument just reiterates that you don't actually _understand_ what an exception is for, because you're basically just repeating your initial thesis.