Comment by rzwitserloot

Comment by rzwitserloot 3 days ago

3 replies

> For example they used checked exceptions.

Those are from java 1.0 and thus don't appear to be relevant to the part of the discussion I think this part of the thread is about (namely: "Why doesn't java crib well designed features from other languages?").

> Java went with checked exceptions and nowadays they are almost universally ignored by developers.

They aren't.

Note that other languages invented for example 'Either' which is a different take on the same principle, namely: Explicit mention of all somewhat expectable alternative exit conditions + enforcing callers to deal with them, though also offering a relatively easy way to just throw that responsibility up the call chain.

The general tenet (lets lift plausible alternate exit conditions into the type system) is being done left and right.

vips7L 2 days ago

All modern languages are adopting a checked error system: Rust, Swift, Kotlin, Zig, Gleam; they all have some type of error you must handle.

The problem with Java is that they haven’t added the syntax to make dealing with those errors easy. It’s boiler plate hell.

  • rectang 2 days ago

    Yeah, unwrapping a Result in Rust can often be done via a single character, the chainable `?` operator.

    That’s not the only issue, though: Java also shunts both checked and unchecked exceptions through the same mechanism, conflating them. It’s no wonder that Java’s problematic implementation of checked exceptions has poisoned people against the concept.

jayd16 3 days ago

I suppose you could actually solve it by having a promise that catches the exception like your suggesting with an either result. The C# Task API can do this. It has it's own headaches where now the developer has to pay attention to observing every exception.

Java could do something similar but they have enough promise types already.