Comment by bigstrat2003
6 hours ago
That is not a pitfall, that is the whole point of checked exceptions. By making the errors part of the type system, you get the ability for the compiler to warn you "hey man, that method started to raise a new error so you have to make sure to handle it". That is a great benefit, not a pitfall!
Put another way - it would be a lot easier for the programmer to write code if there were no types checked by the compiler at all, but we recognize that the safety net they give us is worth the additional effort at times when refactoring. So why would the benefits of static type checking be worth it, but not the benefits of static error type checking? It seems to me that either both are good ideas, or neither is.
Types help the programmer. When the compiler gives me a type error, it is telling me about something I messed up and that would otherwise be an error at runtime. Sometimes the type system is wrong and I need an escape hatch. A type system that is wrong too often isn't very useful. For the majority of exceptions, there no useful thing that can be done at the call site to deal with them beyond bubbling them up the stack. A type system that constantly makes me explicitly deal with such errors is making my job harder, not easier.
There are plenty of errors/exceptions that don't need to be bubbled up the call stack. I don't think that's the main issue with them. Like you say the issue with checked exceptions is that there is no escape hatch to shut the compiler up and panic if you can't handle an error or its not possible. They desperately need a short hand like Rust's ?, Swift's try?, or Kotlin's !!.
In a modern language that has checked errors that just becomes something like:
The pitfall was if I have to extend it with new exceptions, one had to go and fix all code that was handling it to handle this one too.
Works great in monorepo, but not sure if code is spread out.
Right, but I think the GP is saying that, with checked exceptions, the 'throws' list is part of that function's API. Changing the 'throws' list is exactly like changing the arguments to or return type of the function.
It's not so much a "pitfall" as it is an intended part of the deal.
It just turns out that many people hated it, so most of the time functions omit the 'throws' list and throw unchecked subclasses of RuntimeException. Which also has its trade offs! (Or "pitfalls", if you want to use the same term.)