Is Throwble a checked Exception

[Simran Dass]

When we give :-

throw new Throwable();

If we do not either handle or declare the exception compilation fails.
So is Throwable a checked exception. What should be the answer to foll question :-


a) Throwable is a checked exception ? ( True or False)

[Christophe Verré]

What is the definition of an unchecked exception ? If you know it, you'll know what type of exception Throwable is. Check the answer in the Java Specification.

[Simran Dass]

The specification says : -


The unchecked exceptions classes are the class RuntimeException and its subclasses, and the class Error and its subclasses. All other exception classes are checked exception classes.


So, this means Throwable is a checked exception

[Ankit Garg]

 

Simran Dass wrote: So, this means Throwable is a checked exception

Yes that's right. You could've also created a simple program which throws an object of type Throwable and not catch it...

[Neha Daga]

 

The Throwable class is the superclass of all errors and exceptions in the Java language

So it can be both checked and unchecked.

[Tim McGuire]

 

So it can be both checked and unchecked.

Hold on a second...
It isn't both checked and unchecked

The unchecked exceptions classes are the class RuntimeException and its subclasses, and the class Error and its subclasses. All other exception classes are checked exception classes.

is Throwable a RuntimeException or one of its subclasses? No
is Throwable an Error or one of Error's subclasses ? No

if you do as Ankit suggested and try to throw an unchecked throwable, it won't compile

[Neha Daga]

Throwable is super class of RuntimeException and Error so it contains them too, thats why when you throw a throwable you can catch it or not as per your wish.
If you dont catch a throwable compiler will not complain which is the case with RuntimeExceptions and Errors.

Throwable is superclass of all Exceptions, so it contains both checked and unchecked exceptions.

[Ankit Garg]

 

Neha Daga wrote:when you throw a throwable you can catch it or not as per your wish.
If you dont catch a throwable compiler will not complain

Did you try it out??

class ExceptionTry {
public static void main(String[] args) {
throw new Throwable(); //error
}
}

[Harpreet Singh janda]

Yow can't throw a Throwable without catching it. You can't say that it is both checked and unchecked exceptions

[Neha Daga]

sorry, I didn't try it and gave a wrong answer.
And i was a bit confused in my thoughts and I guess I wrote the other way round.

you guys are correct.

[Simran Dass]

Thanks

I had already tried it with code before posting the question but was
confused (same confusion as Neha's). My question contains -

throw new Throwable();

If we do not either handle or declare the exception compilation fails.

[Jan Paul Brasser]

I was looking into this today, as the exception-class-hierarchy is a bit confusing. Throwable and Exception are a bit special in CheckedException-land. They are checked exceptions in the sense that they must be caught if thrown. However. The compiler doesn't know if a method throws either one of them. So, for instance.

Normally, if you would try to catch a checked exception of a method that doesn't throw it (Feel free to change IOExcepton to any other checked exception that extends Exception):
------------------------------------------------------------------------------------------------------------------------------------------------------------------

void something() {}
public static void main(){
try{
something();
} catch (IOException e){.                                          // -> compiler complains. method does not declare IO exception, unreachable code.
// do some magic to handle that which cannot possibly occur/ unreachable code.
} 

------------------------------------------------------------------------------------------------------------------------------------------------------------------
Now, change IOException e to either Exception or Throwable. The compiler issue disappears.  The thing here is that RuntimeException also inherits first Throwable, then Exception, which means that a declared Throwable / Exception may well be a RuntimeException - at runtime. The compiler can't know if the catch block will prove to be unreachable. It may well catch a runtime exception, at runtime.

I'd say that a better design with hindsight would have been to have something like a problem abstraction that a CheckedException and RuntimeException  class would inherit/implement, so that they would divert at the right point.

[Paul Clapham]

 

Jan Paul Brasser wrote:I'd say that a better design with hindsight would have been to have something like a problem abstraction that a CheckedException and RuntimeException  class would inherit/implement, so that they would divert at the right point.

There's also Error, which is for things which happen when something in the JVM is seriously and unexpectedly broken. But yeah, it's always seemed odd to me that RuntimeException was embedded in the taxonomy of Exception. Perhaps having Error, RuntimeException, and Exception be the three subclasses of Throwable could be that design? Then Exception and all of its subclasses would require being caught, and nothing else would.

On the other hand I generally assume that when the Java designers made a decision which looks strange to me, they probably knew what they were doing. But on the other other hand maybe that was less so in the Java 1.0 days.

[Paul Anilprem]

From an application programmer prespective, I think the hierarchy is fine. For the method caller there is one root class i.e. Exception, which can be used to catch all application exceptions, and for method developer, there is a special RuntimeException, which they can use if they don't want to force the caller to catch it.

Creating separate lineages for checked and unchecked exception would force a method caller to have two catch clauses if they want to catch all application exceptions.

Throwable is an incidental class for having a common root and Error is not for application programmers anyway.

[Stephan van Hulst]

I agree that the hierarchy is mostly fine.

Personally I would have gotten rid of RuntimeException and I would have made Exception unchecked. Then I would have added a subclass CheckedException that's the common ancestor of all checked exceptions.

But really, the existing hierarchy is fine too.