Could anyone tell me what would have been the pitfalls of implementing exceptions in JavaLanguage ALSO as interfaces instead of only classes at present? i.e., the methods can throw interfaces in their contract and try blocks can catch interfaces.. -- AnonymousDonor

Wanna illustrate with a code example? -- anon2

 public interface Throwable {/*details go here*/}

 try {
 ....
 }
 catch(Throwable e) {
 ....
 }
JavaLanguageSpecification requires all exception to be derived from a class Throwable. I was asking about why the decision was made to use a class an not an interface.

''Java exceptions must all be descendants of the class Throwable. Since Throwable is a class and not an interface you cannot define an exception to be the implementation of an interface. I'm not sure if you are asking whether it is possible or how it could be done (given that it is not possible).''

''When you say "implementing exceptions" I assume you mean creating user-defined exceptions. You can search this wiki for pages whose titles contain the word "exception" to find some patterns/anti-patterns for exception creation/handling.''

No. My question was on the design decision of JavaLanguage. There throwable is a class. If it was an interface, then it would have solved some problems especially multi-typed exception (Where an exception is of both type A and B). I think it's more difficult if interface was used for exception handling. In Java, printing of stack trace is a native operation. If interfaces were allowed then it would have been more difficult? But still there could be workaround for this problem also. -- AnonymousDonor again.

''Let's see an example of some code you would like to write with multi-typed exceptions.'' -- anon2

----
The following is probably not so right...

 package com.acme.product.framework;

 public interface InvalidValueException extends Exception {

 }

 ****

 package com.acme.product.controller;

 public interface ControllerException extends Exception {

 }

 public interface Controller {
    public User getUser(Context c) throws ControllerException; // NOTE that here the interface is fixed.
 }

 public class MainController() implements Controller {

    public User getUser(Context c) throws ControllerException { // Throws has obligatory ControllerException in interface.
     ...
    }
 }

 public class IllegalUserInput implements ControllerException, InvalidValueException {
  // This is the one that the above implementation actually throws.
 }

 // some code
 ..
 try {
  mainController.getUser();
 }
 catch (InvalidValueException uiError) {

 }
 catch (ControllerException e) {
 }
Here the main deviation from all accepted OO practices is that we catch an exception that is NOT declared in the contract of the method. But the calling method also wants to catch those exceptions that are of particular type InvalidValueException. This means from a conceptual point of view that "I want all the exceptions that are invalid value to be handled separately from exceptions caused by a bug". Note that ControllerException can not be derived from InvalidValueException as controller exceptions are general. Moreover, I'm probably using another framework so I can not change the interface of the controller methods to include InvalidValueException in their contract.

''Well, you can always wrap the framework. Probably a good idea, anyway; you don't really want to embed a third-party framework all through your code.''

----
James Gosling answers the question "why is Throwable not an interface?" here:

http://java.sun.com/features/2002/03/gosling.html?source=jdc_news&date=20020430

Basically, he says that he wanted every Throwable to have some basic state (like a stack trace, I suppose) associated with it, and the only (simple) way to do that was to make Throwable a class.

----
CategoryException | CategoryJava