> Sometimes I've even had to throw a different type of exception than declared by an interface method and was left to either refactor tons [...] I see that thi

> Sometimes I've even had to throw a different type of exception than declared by an interface method and was left to either refactor tons [...] I see that this is inconvenient. This might be the essence of the whole thing here. It is way worse than adding a new argument to a function! 1. There is no way to overload a function with different Exception clauses. 2. You not only need to touch the call sites but also parts of the stack that led to the call sites. > I've had to write code to open a file that I know will always exist How can you ever be sure a file exists? I can be sure a function or a variable exists if I declared it. Files can be manipulated by other processes, USB drives are ejected, etc. You can never be sure they stay where it was. Even if I created the file one line above, I technically still have a potential race condition. > For functional programming languages, I think it's a lot more convenient to not have checked exceptions. There is a clear tradeoff here. E.g. when writing python or bash scripts I seldom care to catch errors. Let it crash fast and return a stack trace. For production grade software you usually want to much more careful and handle exceptions explicitly. Checked exceptions are clearly targeted for the latter.