Doubt in exceptions thrown by JVM and by programmer

[Riya Pant]

Hi,
I am preparing for SCJP5.I have a doubt in What does it mean for an exception to be thrown by JVM or thrown progammaticaly. I thought of them as "Checked exceptions thrown progamatically and Unchecked exceptions are thrown by JVM". But in chapter 5 of K&B, Page no.370, NumberFormatException and IllegalArgumentException are shown as thrown programatically but these are Runtime Exceptions. Please clerify ..

[khushhal yadav]

Hi Riya Pant

There is nothing like JVM throwing Exception..

JVM can only handle exception..Even there is nothing like JVM declaring an exception..

exceptions are always thrown by Programmer..
Or throwm at Runtime..
So they can be either Runtime(unchecked) or Checked Exception..

In case of Checked Exception,
Programmer has had to either declare or handle exception..
Otherwise, he will get Compile time error..

However in case of Runtime Exception,
He won't get Compile-time error..
He can go even without declaring or handling them..
JVM itself is capable of handling Runtime Exceptions..
But he won't be able to proceed with the normal execution of program..
For that he has had to handle them properly..

So it's always good to let your program crash by Runtime Exception..
And provide enough handling to make the program proceed with normal execution..

Regards..

[Riya Pant]

Hi Khshhal,
yes i understand the concept of Checked and unchecked exceptions. But can you check in chapter 5 of K&B, Page no.370,, here they have given a table of exceptions thrown by JVM or programatically.

[Riya Pant]

khushhal .. I am sorry for spelling your name wrong ...

[khushhal yadav]

Sorry Riya Pant

I don't have that book..
And moreover right now I am in office..
It's not possible for me..

Regards..

[khushhal yadav]

And pleaze

For any theory information, don't rely on any book..
Sun Official website www.java.sun.com is the best destination for
any theory help..

Other things are best for practice and mock test..
And that's what I do..
And till now have doing well and good in whatever I ve done..
Whether that's making a real program or taking any test..

Regards..

[Jim Yingst]

[khushhal yadav]: There is nothing like JVM throwing Exception.. [...] exceptions are always thrown by Programmer..

That's not correct. One common example of an exception thrown by the JVM rather than the programmer (usually) is NullPointerException. Others include ClassCastException, ArrayStoreException, and many errors like OutOfMemoryError. For all these, it's possible for a programmer to throw this themselves, but it's much more common for the JVM to throw it, as soon as it detects the situation described by the exception.

[Riya Pant]: I thought of them as "Checked exceptions thrown progamatically and Unchecked exceptions are thrown by JVM".

As far as I remember, all exceptions thrown by the JVM are either RuntimeExceptions or Errors. However this does not mean that all RuntimeExceptions or Errors are thrown only by the JVM. NumberFormatException and IllegalArgumentException are, indeed, two examples of RuntimeExceptions that are thrown programmatically. There are many others. All RuntimeExceptions can be thrown programmatically (try it!), and many are only thrown programmatically.

[Chandra Bhatt]

Riya Pant:

What does it mean for an exception to be thrown by JVM or thrown progammaticaly. I thought of them as "Checked exceptions thrown progamatically and Unchecked exceptions are thrown by JVM". But in chapter 5 of K&B, Page no.370, NumberFormatException and IllegalArgumentException are shown as thrown programatically but these are Runtime Exceptions. Please clerify ..

In case you want to recover from the exceptional case, or continue with the
flow of the program, you handle the exception.

It is nothing like Runtime type exceptions can't be handled. JVM throws the
exception when it encounters something wrong happening at runtime, as you
divide a number by zero, or try to call a method on the object that has
been set to null and so on. It is matter of run time that is why called
runtime thrown exception.


Checked and Unchecked exception:
You must handle or declare the checked exception.
You are not forced by the compiler to handle unchecked exceptions.

Thanks,
[ June 26, 2007: Message edited by: Chandra Bhatt ]

[khushhal yadav]

Ok Jim Yingst

I got U..
But the cause of throwing them by JVM is
the code that programmer has written..

If he has not done anything wrong in performing any logic..
I don't think still JVM can throw exception by it's own..

It seems to me as if there is a default handler in JVM..
which handles these exception rather than throwing..
Though your program terminates, it's a different thing..

About Errors, ya I am ok , they are thrown by JVM..

Pleaze Clear this doubt to me..

Regards..

[Chandra Bhatt]

If he has not done anything wrong in performing any logic..
I don't think still JVM can throw exception by it's own..

It is not matter of logic or so. If you are performing any arithmetic
operation chances are that your code may throw java.lang.ArithmeticException, or there may be like you pass wrong
formatting argument to the printf method, causing IllegalArgumentException
(it's parent class), or some operation that may cause the exception. You
don't say for sure, but you handle that putting the critical code inside the
try block. As you are not forced to handle or declare the RuntimeException,
when your code runs and JVM sees that the operation is wrong, it throws the
exception telling you that this particular code caused the exception, and
doesn't handle that.

void method(int x) {
    int y=10/x; //Line #1 
}

Here your logic is perfectly ok, nothing wrong, but you are not sure about
what can x be. So you suspect it x is passed as 0, the code will throw
divide by zero exception. Compiler does not know, what wrong there could be.
So for sake of saving your program horrible death, you put the code in try
block:

try{
   int y=10/x; //Line #1
}catch(ArithmeticException ae) {
    ae.printStackTracee();
}

Now in case, value of x is 0 causing your code throw an exception, the
exception is handled and you get the stacktrace of that from top to root.

Thanks,

[khushhal yadav]

Hi Chandra Bhatt

that something i know you will get ArithmeticException for division by 0 in case of integer..

But that is the programmer mistake, he should take care of all such things..
Means there is mistake on the part of programmer..
He has to make it sure that his program works irrespective of any input from user

But I want know, if I have taken care of all these things..
JVM by it's own choice can't throw exception..

Regards..

[Riya Pant]

Chandra. i got your point.What I understand is

We can handle unchecked exceptions also if we know that a perticular piece of code can throw that exception and we do not want to stop execution in this scenario.In this case that exception will be called as thrown progamatically?

.

But if tis is so..we can handle any exception we like..as we can write the code in try catch block where we are doing some casting and handle ClassCastException.I know this is weird but we can do this.In this case, how can we draw a line between two JVM thrown and Programatically thrown exceptions.

The reason i am enforcing on the term programaticaaly is I saw 1-2 questions in mock exams to distinguish between JVM thrown and programatically thrown exception.

[Manfred Klug]

Originally posted by khushhal yadav:
But that is the programmer mistake, he should take care of all such things..

But the JVM throws the exception.

[Manfred Klug]

Originally posted by Riya Pant:
In this case, how can we draw a line between two JVM thrown and Programatically thrown exceptions.

The line a simple question. Who has generated the exception?

public class Test {
    public static void main(String[] args) {
        int result = 7 / 0;  // JVM thrown Exception
        throw new RuntimeException(); // Programatically thrown exception
    }
}

[Chandra Bhatt]

Hi Riya,

From exam perspective:
Refer to page # 370 of K&B, that is sufficient as I see.

Exception typically thrown by the JVM never means, programmer can't throw that exception.


I give you some examples, with respect to page 370 or K&B:

ArrayIndexOutOfBoundsException: Typically thrown by the JVM:

Even you can throw that exception as:

void printNum(int index) {
    int a[] = new int[]{12,13,14,15,16};
    if(index <0 || index>4) {
       throw new ArrayIndexOutOfBoundsException();
    }
}

ClassCastException: typically thrown by the JVM, but lets try to throw it programmatically

class Animal{}
class Dog extends Animal{}
 
void assign(Animal a1) {
if(a1 instanceof Dog) {
    Dog d1 = (Dog)a1;
}else {
    throw new ClassCastException(); 
}
}

This means, a1 must refer to Dog object at run time because inside the
method we will assign a1 to Dog ref variable. So we first checked up that,
if a1 refers to Dog object at runtime, its ok, otherwise we throw
ClassCastException. But we (programmer typically don't throw the
ClassCastException and leave this job over JVM to decide).


NullPointerException Typically thrown by the JVM,
but let us throw it programmatically

class Animal {void eat(){System.out.println("Animal eat");} }
 
class Animaltest() {
   public static void main(String... args) {
       Animal a1 = new Animal();
       callMethod(a1);
       a1=null;
       callMethod(a1); //it will cause the callMethod to throw NPE
   }
 
   static void callMethod(Animal a1) {
      if(a1 !=null) {
         a1.eat();
      }else {
          throw new NullPointerException();
      }
   }
}

Thanks,

[Chandra Bhatt]

Khushal:

But I want know, if I have taken care of all these things..
JVM by it's own choice can't throw exception..

Exceptions are there for both, attentive and ignorant programmers. They are
at there place to handle the situation, if something goes wrong, instead of
dieing ridiculous death, it has provision of throwing exceptions. All
programming code written inside exception handling code. Java compiler
does not excuses you, you must handle or declare the exceptions known as
checked exceptions but you are free in RuntimeException(unchecked exception)
in this regards.

Cases where even careful programmer can't guess well:

#1 How could you guess, at run time some IO thing would cause
problem in writing file. That is why there is java.io.IOException .

#2 Suppose you get some wrong argument from the user from the
console. So it is up to you, how do you handle this, validate the data
before putting it to the logic of your code.

#3 There are zillions of objects in the memory and your program
has active references to all the objects. Even GC is not taking place for that reason. You machine is running out of memory. So JVM throws error
saying out of memory.

#4 Your method recurses very deeply and as you know every method call
is put on the stack. So in this case StackOverFlowError is the only
option the JVM has to throw.

As like there are hundreds of examples where exception handling is really
useful thing. What languages like C and C++ fails is strong exception
handling mechanism Java specially has for us.

Thanks,
[ June 26, 2007: Message edited by: Chandra Bhatt ]

[Riya Pant]

thanks everyone.. Now its more clear.