CODEWITHSUNDEEP
java
Chris
Chris

Reputation: 5654

Naming convention in JDK: java.lang.Throwable

All the interfaces in Java like Serializable, Cloneable, Observable etc are suffixed with "-able". However, java.lang.Throwable is not an interface but a class.

I understand the usage of java.lang.Throwable but I cannot understand why it is named in that fashion. Is there a specific reason for this anomaly ?

Upvotes: 2

Views: 341

Answers (2)

Pedantic
Pedantic

Reputation: 5022

An interview lost to the dustbins of the internet with James Gosling, an ex-VP of Sun and a main architect of Java explains why the decision was made to make Throwable a class and not an interface. The main reason was because throwables needed to track state:

JDC: 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.

JG: 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.

Upvotes: 3

Nishant
Nishant

Reputation: 55866

The Throwable class is the superclass of all errors and exceptions in the Java language. Only objects that are instances of this class (or one of its subclasses) are thrown by the Java Virtual Machine or can be thrown by the Java throw statement. Similarly, only this class or one of its subclasses can be the argument type in a catch clause.

It encompasses all the things that can be thrown, in much the way as an interface/abstract classes do. I guess that should be the logic behind having a -able suffix. While this is not a point of argument... you should not, in general, assume anything that ends with able is an interface.

Update
Another example from real life, is in one of my projects... I had to make a (abstract) super class whose subclasses can be cached (in MemcacheD). It abstracted all the logic required to add, delete, update cache. What would be a good name for it? I named it Cacheable. The idea is if it's Cacheable it will be cached.

So, it's just semantics -- nothing to with naming pattern. The only naming pattern Java has are given here: Java Naming Convention

Upvotes: 0

Related Questions