What I am expecting is that compiler could sort the catch clauses and put then in the class file in sorted fashion based on the class hierarchy at compile time. However, this need not affect the runtime resolution of catch clauses. That is, the catch clause executed at runtime is chosen based on the runtime type of the exception being raised.

They aren’t comparable because overloading results in a runtime reference to a method with a specific signature. Exceptions, on the other hand, are not specific—a single “catch” clause can catch many subtypes of exceptions.

They are comparable because with both exceptions and overloading, the Java specifications leave it to the programmer to deal with the potential mismatch between compile-time and run-time. The proposal would take that control out of the hands of the programmer in the case of exceptions.

The compiler cannot determine (with 100% accuracy) which exceptions will be specializations of which other exceptions when the code is actually executed.

The same limitation applies when compiler is trying to resolve which overloaded method is being invoked. The most specific overloaded method is chosen based on the inheritance hierarchy at compile time. Yes, this hierarchy could be broken at runtime during the invocation of the overloaded method, just like for exceptions.

If the compromise is ok for overloaded methods it should be ok for catch clauses.

Sometimes to understand the why’s of Java, you need to remember that Java is 100% dynamically bound. The hierarchy of exceptions at runtime will not necessarily be the same as the hierarchy that existed at compile time.

The compiler cannot determine (with 100% accuracy) which exceptions will be specializations of which other exceptions when the code is actually executed. Reordering the clauses at compile time would work most of the time, but could result in erroneous results. This is something that is better left to the IDE, where the programmer can choose to do it or not and can intervene if the resulting order is inappropriate.

Sachin: I believe overloaded method calls are resolved at compilation time itself

Yes. Thanks for correcting!

Sachin: the question is still valid because the compiler can still be responsible for re-ordering catch clauses

Yes, that was what I was hoping the compiler would do.

My thoughts on this topic – but before that I just wanted to mention that I believe overloaded method calls are resolved at compilation time itself and are statically determined so there is no way the ‘right’ overloaded method call can be made cheaply at runtime. It is method overriding (polymorphic behaviour) that is dynamically determined.

I think it is possible that runtime performance of exception handling is a big reason why the Java runtime expects exception handlers to be organized the way they are (most specialized to most generalized). I guess the exception handling code can then just work its way down the list and the first handler that returns true for Class.isAssignableFrom would work (I don’t know what the actually byte code generated is so I may be wrong). If it was required to determine the best handler out of them all at runtime, all handlers have to be visited and the best one recovered at runtime making it much slower.

However, despite this the question is still valid because the compiler can still be responsible for re-ordering catch clauses as expected by the runtime and not pose the restriction on the programmer. Here, I believe the reasoning could very well be usability. I would argue that providing this ‘flexibility’ is less usable because, although there is more flexibility while programming, the code becomes less maintainable. It is no longer possible to read the exception handling code without manually performing this operation every time you read such code. Making the programmer do it once is an overhead that saves time many times over.

If Java were designed with a philosophy of “more power to the programmer” then I would expect this would be supported (and we would then have had someone suggest as a good coding guideline that everyone organize their catch clauses this way for readability) however Java does take the more restrictive approach to programmer flexibility and this seems to be in keeping with that.

My guess is that perhaps these guys first decided to have mutiple inheritance in java and write exception handling based on that. They later backed multiple inheritance off but left this as it was