Win a copy of Spring in Action (5th edition) this week in the Spring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

is CloneNotSupportedException Checked Exception.  RSS feed

 
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i tried this code
in the class
which do not implements Cloneable.
Object ob=new s90().clone();
but this caused a compile time error that CloneNotSupportedException must be caught.
pls explain
 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi rahul,
clone() is in Object class. Its signature is like below
protected Object clone() throws CloneNotSupportedException
Which says that this method clone() will throw an exception if the object's class does not support the Cloneable interface.
CloneNotSupportedException is a Checked Exception.
Refer Java API- Object class.
A method's checked exceptions need to be listed in that method's throws clause. Errors and RuntimeExceptions are not required to be listed in a method's throws clause.
HIH

Originally posted by rahul kumar:
i tried this code
in the class
which do not implements Cloneable.
Object ob=new s90().clone();
but this caused a compile time error that CloneNotSupportedException must be caught.
pls explain


 
Ranch Hand
Posts: 5390
1
Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by chandrashekar munukutla:
[b]Errors and RuntimeExceptions are not required to be listed in a method's throws clause.
HIH
[/B]


Hi chandra
1. are you sure that Error are not checked also...
2. can we throw Error object??
------------------
Regards
Ravish
 
Ranch Hand
Posts: 267
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is what the API doc says about Error & Exception classes
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.

The class Exception and its subclasses are a form of Throwable that indicates conditions that a reasonable application might want to catch.
From the above definitions of Error & Exception classes it is clear that you have to handle exceptions & not errors.
Hope this explanation helped you.
Roopa.

Originally posted by ravish kumar:
Hi chandra
1. are you sure that Error are not checked also...
2. can we throw Error object??


 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi rahul,
wish u all the best for tommorow.
and yes do post your result and tell us your experience.
neha.
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ONE
I know that we need not throw any Errors as JVM will take care of those errors.
And I also know that this discussion is not so appropriate and related to programmer certification(correct me if I am wrong.)
-----------------------------------------------------------------
TWO
The following is from Java API
What API says about Error is,
(Verbatim)
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions.
A method is not required to declare in its throws clause any subclasses of Error that might be thrown during the execution of the method but not caught, since these errors are abnormal conditions that should never occur.
Question:
When the API says "not required", does it mean "we cannot".
-----------------------------------------------------------------
THREE
public class ThreadDeath extends Error
An instance of ThreadDeath is thrown in the victim thread when the stop method with zero arguments in class Thread is called.
An application should catch instances of this class only if it must clean up after being terminated asynchronously. If ThreadDeath is caught by a method, it is important that it be rethrown so that the thread actually dies.
The top-level error handler does not print out a message if ThreadDeath is never caught.
The class ThreadDeath is specifically a subclass of Error rather than Exception, even though it is a "normal occurrence", because many applications catch all occurrences of Exception and then discard the exception.

Question:
Since stop() method is depricated, does it mean that this ThreadDeath is never thrown. If not, what are other situations when this ThreadDeath is thrown.
---------------------------------------------------------------------
FOUR
Thinking in Java (Bruce Eckel)
(in page 549)says,
Error represents compile-time and system errors that you don't worry about catching (except in special cases).
This is not a certificatoin book. But it is accepted as standard book.
Question:
Now what are these special cases. When do these occur. Does this mean that we can throw Errors.
And also according to JLS (11.2.1), he says that
"Those unchecked exception classes which are the error classes(Error and its subclasses) are exempted from compile-time checking because they can occur at many points in the program and recovery from them is difficult or impossible."
-----------------------------------------------------------------
FIVE
Actually the book I reffered to before answering was Java 2 how to program by Deitel and Deitel. (on Pg 712 [14.10] Throws Clause, 5th line from bottom)Which says as below .

Because Errors and RuntimeExceptions can be thrown from almost any method, it would be cumbersome for programmers to be required to list them; these are not required to be listed in a method's throws clause, and hence are said to be "unchecked."
All non-RuntimeExceptions a method can throw must be listed in that method's throws clause, and hence are said to be "checked."

Question:
Actually in the above paragraph,in the line
method's throws clause, and hence are said to be "unchecked."[/b] the throws should be throws (I guess).
This is what I read and posted a reply.
-----------------------------------------------------------------
SIX
[ by the way, Now before replying I also checked Sun's Java tutorial. They didn't mention more details on Errors.]
In RHE,
Summary of chapter 5 (heading: Exception Throwing)
"A method cannot throw any Throwable other than RuntimeException, Error, and subclasses of these, unless a throws declaration is attached to the method to indicate that this might happen."
from khalid Mughal's PGJC,
Except for RuntimeException, Error and their subclasses, all
exceptions are called "checked" exceptions. Exceptions defined by Error and RuntimeException classes and their subclasses are known as "unchecked" exceptions, meaning that a method is not obliged to deal with these kinds of exceptions.
(for hierarchy refer API.)
Finally the JLS says (11.2)
"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. Additional exception classes, both checked and unchecked, may be declared by programmers."
But what I want from "Java GURUS" here at Javaranch is to confirm me the point whether we can throw Errors by mentioning it in the throws clause of a method or not.(though I am not interested in throwing one).
If we are asked a question say,
Which of the following statements are true.
A. A programmer can throw an Error
B. A RuntimeException is an Unchecked Exception.
C. Error and all its subclasses are classified as Unchecked Exceptions.
D. Uncheked exceptions are handled by JVM and a programmer is not specifically required to handle them.
What should we select?
thanks
Chandra!


[This message has been edited by chandrashekar munukutla (edited October 24, 2001).]
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Q2
At least in this case not required is not the same as canot.
Just create an Error in a method and throw it without being specified at declaration. The behaviour is the same as unchecked exceptions. thou Errors are not Exceptions
Q3
It looks so, at least while code in API classes don't call stop.
Q4
The ThreadDeath is one of them IMHO.
Q5
A true
B true
C false
D Unchecked Exceptions are managed by the JVM in the same way as checked ones. The difference is the constraint that the compiler places on Checked Exceptions.
 
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The following page
checked and unchecked
exceptions,
contains a list of checked and unchecked exceptions.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!