Java's checked exceptions fit the 5 criteria:

1. It either `throws` or it doesn't

2. If the function `throws` you have to wrap it in try/catch, or make your function `throws`

3. Your function is `red` if it `throws` the same exception.

4. see (2)

5. See the FileReader class in core.

Now, C++ exceptions might not satisfy all of these, but the problems CheckedExceptions were meant to solve still exist in C++ and as a result some style guides forbid them entirely. Like async, the biggest problem with exceptions were the ergonomics.

▲

sheept an hour ago | parent | next [-]

#3 is not satisfied, as you noted in #2. You can call `throws` methods from non-`throws` methods by wrapping the call in a try catch, and `throws` methods can call non-`throws`. There isn't an exclusivity asymmetry like there is for JavaScript async.

▲

dnautics an hour ago | parent | prev | next [-]

Ok, sorry it's been about 20 years since I last javad IIRC you didn't have to declare exceptions in your function signatures. However, wrapping in try/catch seems to violate #3. Try catch is not a heavy lift of a seam between red and blue

To be fair, #3 seems to have shades of grey. In some pls, you can call an async function from a sync one by wrapping it in a whole damn event loop system. Should that count?

	▲	Terr_ an hour ago \| parent [-]
		> Ok, sorry it's been about 20 years since I last javad and you didn't have to declare exceptions in your function signatures. You're probably remembering RuntimeExceptions, which are a subgroup [0] that are not "checked" meaning the compiler does not require method signatures to declare "I might emit this." [0] https://docs.oracle.com/en/java/javase/26/docs/api/java.base...

▲

Terr_ an hour ago | parent | prev [-]

> Like async, the biggest problem with exceptions were the ergonomics.

I know it's not a popular take, but I prefer the idea of Checked Exceptions over unchecked ones [0], and suspect current opinions would be vastly different if Java had shipped with some sweet syntactic sugar for: "If an exception that is of kind A or B or C occurs, automatically throw another checked exception X with the original exception as a cause."

> Ex: If I'm writing a tool to try to analyze and recommend music that has to handle multiple different file types, I might catch an MP3 library's Mp3TagCorruptException and wrap it into my own FileFormatException.

This would reduce the temptation for developers to ruin the type-safety characteristics by wrapping everything in a RuntimeException just to get the ticket out the door.

[0] https://news.ycombinator.com/item?id=42946597

▲

skybrian 13 minutes ago | parent [-]

The problem with Java's checked exceptions is that it has too many kinds of exceptions to choose from and they're overly specific. Compare with Go, which has a single error interface and had it from the beginning, so it's used everywhere. Returning a new kind of error is always a local change, unless it's a function that didn't previously report errors at all.

Type systems permit either standardization or fragmentation and that's an ecosystem issue. Another example is that a language without a strong consensus on which string type to use will result in a fragmented ecosystem when each library goes its own way.

	▲	Terr_ 3 minutes ago \| parent [-]
		[delayed]