why is java.lang.Throwable a class?
Asked Answered
L

4

44

In java adjectives ending in -able are interfaces Serializable, Comparable etc... So why is Throwable a class? Wouldn't exception handling be easier if Throwable were an interface? (Edit: e.g. Exception classes don't need to extend Exception/RuntimeException.)

Obviously, changing it now is out the question. But could it be made abstract? Wouldn't that avoid the bad practice of throw new Throwable();

Levy answered 23/5, 2010 at 0:45 Comment(4)
"Wouldn't exception handling be easier if Throwable were an interface?". I am curious ... why do you think it would?Chindwin
I was tinking it would avoid having to have Exception/RuntimeException as a base class. You could do the whole checked/unchecked exception divide with a CheckedException interface.Levy
and what would the advantage of that be? There is certainly no performance advantage, since checked versus unchecked exceptions is only enforced at compile time.Chindwin
I hope it would still be checked at compile time. The point is you gain some freedom with your base class. It's just an idea, and I'm uncertain of the consequences, hence why I asked the question.Levy
S
19

So why is Throwable a class?

I can think of two reasons:

  1. Exceptions have state. In particular, message, cause, and stack trace.
  2. It is easier for the JVM to implement efficient catch blocks. Class hierarchy checks are cheaper than interface checks.

Wouldn't exception handling be easier if Throwable were an interface?

Exception handling is a hard topic regardless of whether exceptions are classes or interfaces. I actually suspect it would make it harder on Java programmers if they have to order their catch blocks based on arbitrary interfaces rather than on class hierarchies.

But could it be made abstract?

In theory, yes. In practice, no. Too much code depends on being able to create an instance of Throwable in order to call getStackTrace.

Straightjacket answered 23/5, 2010 at 0:51 Comment(2)
Class hierarchy checks are cheaper than interface checks. where does this conclusion come from?Genealogy
It comes from personal experience implementing VMs (though not necessarily JVMs). instanceofClass can be implemented by a VM as something like "o.getClass().hierarchy[c.hierarchyDepth] == c" (with bounds check). instanceofInterface must be implemented using some sort of table or looping (perhaps with an inline cache) since it needs to consider all interfaces (including superinterfaces) implemented by all classes in the hierarchy.Straightjacket
D
66

Here's how James Gosling explained his decision:

Java Developer Connection Program: Why is Throwable not an interface? The name kind of suggests it should have been. Being able to catch for types, that is, something like try {} catch (<some interface or class>), instead of only classes. That would make [the] Java [programming language] much more flexible.

James Gosling: The reason that the Throwable and the rest of those guys are not interfaces is because we decided, or I decided fairly early on. I decided that I wanted to have some state associated with every exception that gets thrown. And you can't do that with interfaces; you can only do that with classes. The state that's there is basically standard. There's a message, there's a snapshot, stuff like that — that's always there. and also, if you make Throwable an interface the temptation is to assign, to make any old object be a Throwable thing. It feels stylistically that throwing general objects is probably a bad idea, that the things you want to throw really ought to be things that are intended to be exceptions that really capture the nature of the exception and what went on. They're not just general data structures.

References

Dentition answered 23/5, 2010 at 4:14 Comment(1)
Dr. Java said it best!Hetman
S
19

So why is Throwable a class?

I can think of two reasons:

  1. Exceptions have state. In particular, message, cause, and stack trace.
  2. It is easier for the JVM to implement efficient catch blocks. Class hierarchy checks are cheaper than interface checks.

Wouldn't exception handling be easier if Throwable were an interface?

Exception handling is a hard topic regardless of whether exceptions are classes or interfaces. I actually suspect it would make it harder on Java programmers if they have to order their catch blocks based on arbitrary interfaces rather than on class hierarchies.

But could it be made abstract?

In theory, yes. In practice, no. Too much code depends on being able to create an instance of Throwable in order to call getStackTrace.

Straightjacket answered 23/5, 2010 at 0:51 Comment(2)
Class hierarchy checks are cheaper than interface checks. where does this conclusion come from?Genealogy
It comes from personal experience implementing VMs (though not necessarily JVMs). instanceofClass can be implemented by a VM as something like "o.getClass().hierarchy[c.hierarchyDepth] == c" (with bounds check). instanceofInterface must be implemented using some sort of table or looping (perhaps with an inline cache) since it needs to consider all interfaces (including superinterfaces) implemented by all classes in the hierarchy.Straightjacket
M
3

well Hashtable is also a concrete class! Something that can be hashted.

and what is Cloneable? it is not a correct English word.

Maynor answered 23/5, 2010 at 3:27 Comment(1)
Not to be a grammar nazi, but it should read with a short o. the ona in it is vowel-consonant-vowel which should make the first vowel long. Of course, the English language has more exceptions than a freshman Java mid-term program, but I digress. (Feel free to downvote all my answers forever for the very very bad pun.)Puente
I
-3

FYI

You can not use

void doSomething() throws Serializable

but you can use generics!

<T extends Exception & Serializable> doSomething() throws T

Regards

Impassive answered 10/9, 2012 at 12:31 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.