Win a copy of Real-World Software Development: A Project-Driven Guide to Fundamentals in Java this week in the Agile and Other Processes 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
  • Paul Clapham
  • Liutauras Vilda
  • Knute Snortum
  • Bear Bibeault
Sheriffs:
  • Devaka Cooray
  • Jeanne Boyarsky
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • salvin francis
Bartenders:
  • Tim Holloway
  • Piet Souris
  • Frits Walraven

Check and Uncheck exception doubt ?

 
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,

Illegal State Exception is a subclass of Runtime Exception.
i.e. There is no need to handle it.

I want to ask you that is there any rule Like..Runtime Exception is thrown by JVM and Checked Exception is thrown Programmatically ??

The IllegalStateException is Runtime Exception but as mentioned in page no 370 of K&B it is thrown Programmatically.

Please Help it Really Confused me.

Thanks
 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
NOT ALL RuntimeExceptions are considered to be JVM exceptions.
For example:
NullPointerException extends RuntimeException class but JVM throw this exception when you are trying to use a method of a null object reference.



You can explicit throw same exception, but doesn't make sense, since JVM will throw it anyway.

Also, all exceptions which extends Error's class are considered to be JVM exception and you have no reason to throw them, but nothing can stop you to do that. JVM can throw those exception when it needs.

Programatically exceptions are those exceptions which JVM can't throw them.
For example: IllegalStateException
It's a RuntimeException but JVM can't throw it if you don't explicit throw it.



So you won't see any IllegalStateException on the stack trace, if you don't explicit throw it. JVM doesn't know about it, when it should throw it, since
it doesn't know what an illegal state mean in your code.

If an exception extends RuntimeException class, that doesn't mean it's a JVM exception. But if an exception extends Error class, then you can be sure it's a JVM exception.

What you have to understand is, there is no constrains on what exception you can throw as a programmer in your app. It's up to you, but throwing an exception which JVM can also throw it, doesn't make any sense. Like ArrayIndexOutOfBounds: if you know when you should throw this exception in your code, then you could write the fix code instead.

ArithmeticException extend RuntimeException class - it's thrown when you are trying to divide a number with 0. (6/0), but you don't see any throw clause anywhere in your code.

If you still don't understand the difference, please come up with you questions and i will try to answer.

Viorel
 
Rahul Nair
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,

Runtime Exception is thrown by JVM. I mean to say, There is not a compulsory rule that the programmer must have to Handle or Declare it.

I want to ask you that why it is not thrown by JVM ? and If is thrown completely by programmer How IllegalStateException is grouped Under Runtime Exception ??

Because it Contradicts that IllegalStateException is Runtime Exception and must be thrown by Programmer and Not thrown by JVM ? am i wright ?

Can you please explain me using some appropriate example ?

Thanks.
 
Viorel Craescu
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What an IllegalStateException mean to you?
JVM can't know what an IllegalStateException mean to your code.
For example IllegalStateException is thrown when you try to start a thread which already have been started. It's up to programmer to choose if he want to let user to re start a thread, but the programmer can't choose if he want to let the user to access a method of null object reference, because that's impossible.

A NullPointerException or ArithmeticException are exceptions which are thrown even you don't see any throw clause in your code. JVM knows when it should throw those exception.

Viorel
 
Rahul Nair
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Viorel,


I agree to the above lines. But NullPointerException or ArithmaticException are Uncheck(Runtime) exception, thats why we don't care about handling or declearing the exceptions in our code.i.e. JVM KNOWS ABOUT THIS EXCEPTION



IllegalStateException IS-A RuntimeException and JVM can't know what about this Exception to our code


The above statement is Correct.(or what am i wrong ?) And It's meaning contradicts that both things are opposite to each other. i.e IllegalStateException is a runtime exception but JVM don't know about this exception ???
Also In other words It IS-A RuntimeException and thrown Programmatically

My question is simple If JVM don't about IllegalStateException then why it IS-A Runitme Exception.
why language developers put it in to Checked Exception hierarchies ??

Please reply...
 
Ranch Hand
Posts: 227
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rahul,

Let's underline the basic definition of exceptions:

An 'Error' is either an instance of java.lang.Error or a subclass of the same.

An 'Unchecked Exception' is either an instance of java.lang.RuntimeException or a subclass of the same.

java.lang.Throwable and rest all children of the same (which are not covered under any of the above 2 categories) are called 'Checked Exceptions'.

Checked Exceptions are 'checked' by compiler, and it is reported if they are not explicitly declared (using 'throws' clause) or handled in a method. Hence, the name - Checked Exceptions.

Unchecked Exceptions, as the name suggests, are not 'checked' by compiler. However, nothing stops you from declaring or handling them. These are also called 'Runtime Exceptions', however, I find it a bit clumsy to use this name as every exception is thrown at runtime only.

Beyond this, there are no differences between them. They are exceptions and they break the execution of code in a similar manner.

It is a general notion that we should not handle Unchecked Exceptions. There are different schools of thoughts on this, and I personally follow those who believe that judicially declaring and handling of Unchecked Exceptions should not be a taboo. For example, while converting a string to a number with resiliency can be done efficiently by handling NumberFormatException.


NullPointerException or ArithmaticException are Uncheck(Runtime) exception, thats why we don't care about handling or declearing the exceptions in our code.i.e. JVM KNOWS ABOUT THIS EXCEPTION




IllegalStateException IS-A RuntimeException and JVM can't know what about this Exception to our code



Now, this is what I would like to put focus on. The notion of Checked or Unchecked Exceptions is about 'checking' declaration and handling at compile-time, and NOT about JVM knowing one exception and not knowing the other. While it is true, that certain exceptions are thrown by JVM, and all those are Unchecked ones, but it is certainly not true that EVERY Unchecked Exception is known by JVM (you know, all apples are fruits but not all fruits are apple kind of thing ).

Once we digest this, we can move further. IMHO, OOAD is more of an art than science. There are few decisions which are influenced by business context, and there are no hard-n-fast rules for them. One of those is deciding whether a particular situation is required to be handled by the client of our code-piece. This is where we decide if we need to have a Checked Exception being thrown from our code-piece, or an Unchecked one.

So, if the API designers decided that a RuntimeException, like NumberFormatException will do the job for Integer.parseInt(), they were not wrong about it. It's not really often that we expect something to go wrong here. Usually, we give proper values for conversion.

I hope this helps you in giving a fresh thought on these perspectives.

Best regards,

- Aditya Jha
 
I can't renounce my name. It's on all my stationery! And hinted in this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!