3 ms·

Could some sort of hybrid approach be an improvement? What if we required every function to explicitly declare the types of exceptions it might throw? The compi

Could some sort of hybrid approach be an improvement? What if we required every function to explicitly declare the types of exceptions it might throw? The compiler could enforce it and make it transitive to higher level functions.

tsimionescu 7y ago
Except for the transitive part, this is what Java does. But it's doesn't address the complaints of the article, which is bothered by the non - local control flow and the large cost of the exception machinery in C++, and by the poor interaction between manual memory management and exceptions. Note: I think the article is vastly exaggerated, and completely wrong, at least when looking at managed memory languages.
ben509 7y ago
That was the basic premise of checked exceptions in Java. It's not really related to the type system or anything. The root of the problem is Java compiles each class as an independent module, so any method has to deal with all its exceptions, even if only naming them, or it can't compile. Thus checked exceptions meant you either got huge signatures, or you wound up wrapping them all into other exceptions, which then made them much harder to inspect. And unchecked exceptions made the problem worse. Java uses single-inheritance and put unchecked exceptions on their own branch. This meant you wound up with, for example, IOException and UncheckedIOException with no close common ancestor, so you had to wrap one in the other. So now, in addition to complicated signatures, you are doing more wrapping. I think what might work would be to ditch the checked / unchecked idea, mostly. (You still want to treat errors like division by zero or invalid array indexing as unchecked.) What you distinguish instead is whether methods are "safe" or "unsafe". An unsafe method can still catch some exceptions, it just doesn't promise to catch all of them. The safe method must catch everything. For example, your main method and Thread.run would have to be safe.

tsimionescu 7y ago

Except for the transitive part, this is what Java does. But it's doesn't address the complaints of the article, which is bothered by the non - local control flow and the large cost of the exception machinery in C++, and by the poor interaction between manual memory management and exceptions. Note: I think the article is vastly exaggerated, and completely wrong, at least when looking at managed memory languages.

ben509 7y ago

That was the basic premise of checked exceptions in Java. It's not really related to the type system or anything. The root of the problem is Java compiles each class as an independent module, so any method has to deal with all its exceptions, even if only naming them, or it can't compile. Thus checked exceptions meant you either got huge signatures, or you wound up wrapping them all into other exceptions, which then made them much harder to inspect. And unchecked exceptions made the problem worse. Java uses single-inheritance and put unchecked exceptions on their own branch. This meant you wound up with, for example, IOException and UncheckedIOException with no close common ancestor, so you had to wrap one in the other. So now, in addition to complicated signatures, you are doing more wrapping. I think what might work would be to ditch the checked / unchecked idea, mostly. (You still want to treat errors like division by zero or invalid array indexing as unchecked.) What you distinguish instead is whether methods are "safe" or "unsafe". An unsafe method can still catch some exceptions, it just doesn't promise to catch all of them. The safe method must catch everything. For example, your main method and Thread.run would have to be safe.