I have LOTS of opinions about this topic, but I'll try not to ramble. I always found checked exceptions (Java) to be mostly fine/good. I sincerely believe that

I have LOTS of opinions about this topic, but I'll try not to ramble. I always found checked exceptions (Java) to be mostly fine/good. I sincerely believe that a lot of the hate for them in the last decade is just cargo culting. I get a small dose of schadenfreude when I see someone doing mental contortions to simultaneously explain why Rust's Result type and handling (and similar features in other langs) is awesome, and Java's checked exceptions are terrible and definitely not 95% similar in DX and semantics... The one point against checked exceptions for me is that if I'm trying to model a domain failure, it really doesn't make sense to collect a stack trace. For example, if I'm writing a logIn function that takes a username and password, then it's totally normal for the username and password to be invalid. Why would I want to spend the CPU time collecting a stack trace when someone simply typed in an incorrect password? Do we want to collect a stack trace when the password is correct and the user gets logged in? So, in that sense, I do have a small preference toward expected failure modeling to be somehow different from "true" "exceptions". I do also agree with you that Kotlin's biggest original sin was to throw away checked exceptions without replacing the concept with ANYTHING. Of course, as you've pointed out, they're backtracking on that somewhat by trying to add this concept of errors as a kind of ad-hoc union type. (aside: they also backtracked on their choice to not have type classes because "extension functions are good enough" by trying to do context receivers, which is ending up being really hard and probably more complex than just doing damned type classes in the first place...) I do kind of like the direction that Swift is moving with finally adding specifically typed throw signatures (essentially Swift now has checked exceptions, but they're aren't actually traditional exceptions because they don't collect stack traces and unwind the stack- they're just syntax sugar around a Result/Try type). But, my prediction is that the pendulum is starting to swing back in favor of checked exceptions. In the next decade we'll continue seeing languages adopt mechanisms that are essentially checked exceptions. But, they will be slightly different and definitely called something else so that we don't have to admit that we were wrong to shit on the idea for 15 years. EDIT: Also, I do follow Kotlin developments closely, but I haven't actually worked in Scala for several years, so I had no idea about this capabilities idea. Thanks for the link.