@hongminhee From someone who first coded Java nearly 30 years ago (gulp) … I think the problem a lot of people had with checked exceptions back in the early 00s, at least, is that they were the default pattern. So it meant that what happened was everyone used them for all of their *internal* calls. Which led to basically every function call needing to define what to do with the exception and this added a lot of verbosity. Once we realized “oh, we can use RuntimeException” (unchecked) many of us switched to them. (It was not initially clear because the “Exception” type is checked, but “RuntimeException”, which extends “Exception”, is unchecked)

I think checked exceptions at the API boundary have value, but I’d still - personally - rather use Result types even if not explicit in the language. But I’ll admit that’s not standard practice.

@hongminhee completely agree. More specifically, being able to define exhaustively what kinds of errors an API may throw, enforced by the compiler with automatic docs, etc. is extremely useful and almost required to write reliable software.

@hongminhee Yeah, it's really unpopular one, cause they are not so good to the point being considered a mistake.

@hongminhee 🌶️🌶️🌶️🌶️🌶️