> That's all true. I've become more sympathetic to checked exceptions over time though. I think the issues Java had with it are more to do with poor choice of w

> That's all true. I've become more sympathetic to checked exceptions over time though. I think the issues Java had with it are more to do with poor choice of what to make checked in the standard library. Exactly this. Working on large codebases has made me a fan of checked exceptions. It's certainly the most efficient and elegant mechanism available to communicate real domain violations. Java's mistake was that the vast majority of checked exceptions (IOException, SocketException etc) are clearly RuntimeExceptions. > But I won't be surprised to see some variant of checked exceptions be explored again in the coming years, probably with IDE support. The logical conclusion of checked exceptions is Design By Contract. It would be great to see checked exceptions expressed as real invariants. The syntax might be something along the lines of: 'cancel(Order o) throws TooLateToCancelException if "!o.isWorking()" { ... }' Because checked exceptions are required to express real domain invariants you might as well go all the way and capture those invariants too.