Win a copy of Murach's Java Programming this week in the Beginning Java forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

programmer versus JVM exceptions  RSS feed

 
shambhavi sham
Ranch Hand
Posts: 136
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi all !!!


i would like to know what is the difference between

a programmer thrown exception and a jvm thrown exception with an example if possible .
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 37051
507
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shambhavi,
Welcome to CodeRanch!

This is a programmer thrown exception. You can tell because there is code that throws the exception.


This is a JVM thrown exception.


It throws the exception at runtime without you coding it on purpose.
 
shambhavi sham
Ranch Hand
Posts: 136
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you mam ! 

i would also like to know, why do we explicitly throw an exception such as in :
throw IllegalArgumentException

when and why are programmer thrown exceptions used ?
 
Paul Clapham
Sheriff
Posts: 22268
38
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't forget that the standard API (which you're calling "the JVM") was also written by programmers. You, a programmer, would throw an exception for exactly the same reason as a programmer writing part of the standard API would.
 
João Victor Gomes
Ranch Hand
Posts: 110
11
Eclipse IDE Java Netbeans IDE Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An IllegalArgumentException is normally thrown by a method when an invalid argument is passed to it.

Following Paul Clapham's answer, there is this topic with a nice discussion about this subject. It made me understand just what Paul said: thrown programmatically doesn't mean thrown by you, the application programmer. It means thrown by a programmer, and the Java API was written by programmers. So, for example, some methods of the API may throw an exception about an invalid value, like IllegalArgumentException, or NumberFormatException (which is a subclass of IllegalArgumentException).
 
shambhavi sham
Ranch Hand
Posts: 136
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
alright thanks all , got it !     

i have another question !


in the above code, in line 3, if i do not declare the exception or if i do not handle it inside main(), i have a compiler error.

when the eatCarrot()  method has declared the exception then why should the main() again do it ?? if eatCarrot() method definition throws an exception, it'll be thrown as declared by its respective 'throws' clause in its signature, right ? why should we again declare the exception in main() i.e. in the caller of eatCarrot() ?

 
Nam Ha Minh
Ranch Hand
Posts: 515
Eclipse IDE Firefox Browser Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
shambhavi ss wrote:alright thanks all , got it !     

i have another question !


in the above code, in line 3, if i do not declare the exception or if i do not handle it inside main(), i have a compiler error.

when the eatCarrot()  method has declared the exception then why should the main() again do it ?? if eatCarrot() method definition throws an exception, it'll be thrown as declared by its respective 'throws' clause in its signature, right ? why should we again declare the exception in main() i.e. in the caller of eatCarrot() ?



It's because when you call a method that throws an exception, the calling code must either handle it (by using try/catch structure), or re-throw it to the upper caller, i.e. throws in main() method in your case.
 
João Victor Gomes
Ranch Hand
Posts: 110
11
Eclipse IDE Java Netbeans IDE Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't forget that all checked exceptions are required to be handled or declared when you call a method that throws it.

In your code, NoMoreCarrotsException is a checked exception because it extends Exception. Your method eatCarrot() declares that it throws a NoMoreCarrotsException (which is a checked exception), so what the compiler understands if you don't handle or declare in the main method is "the method eatCarrot() is declaring that it throws a checked exception NoMoreCarrotsException, and the main method is calling eatCarrots(), but is not handling or declaring the exception thrown by eatCarrot(), so I won't allow the code to compile".
So, remember, if a method declares that it throws a checked exception, when you call that method anywhere else in your application, you must handle or declare that exception.
RuntimeException and its subclasses are unchecked exceptions, so they are not required to be handled or declared.

Try this code, and see what happens:

And be aware of the Exception classes hierarchy. All the classes that inherits from Exception, other than RuntimeException and its subclasses, are checked exceptions.
 
shambhavi sham
Ranch Hand
Posts: 136
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks a lot helpers !         

i also would like to know ,

1. why a class is allowed to declare a subclass of an exception type ?
2. why a subclass is not allowed to declare a new checked exception that is not declared its parent class ?
3. why a subclass is allowed to declare a new unchecked exception that is not declared its parent class ?
 
João Victor Gomes
Ranch Hand
Posts: 110
11
Eclipse IDE Java Netbeans IDE Postgres Database Tomcat Server
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
shambhavi sham wrote:
1. why a class is allowed to declare a subclass of an exception type ?
2. why a subclass is not allowed to declare a new checked exception that is not declared its parent class ?
3. why a subclass is allowed to declare a new unchecked exception that is not declared its parent class ?


I believe you are talking about method overriding, right?

Basically, when overriding a method of a superclass, we are not allowed to declare a new checked exception because we need to explicitly handle or declare it (as I said earlier). Let's see if I can help you with the following code:

As you might know, the code above doesn't compile, but let's talk about it:

Line 1 - In the Vehicle class, we are creating the start() method that throws a BatteryException, which is a checked exception.
Line 2 - The Car class extends Vehicle, and we are trying to override the start() method, but now, we are declaring a new checked exception, so it won't work, since we are just allowed to declare the same exception or a subclass of the exception of the parent's method (I'll explain later why it wouldn't make sense to allow this declaration)
Line 3 - We are creating a reference variable of type Vehicle, and creating a Car object and assigning it to the variable (because Car is a Vehicle).
Line 4 - Here is the point. At compile time, the call car.start() refers to the start() method of the Vehicle class, since the variable is of type Vehicle. The method will be overridden at runtime, because of the object's type. So, we are supposed to handle or declare a BatteryException, because the start() method of the Vehicle class is declaring it.
Thus, line 5 is trying to catch a BatteryException, but if the overriding method of the Car class (which contains the method that will be used at runtime by the Car object) was allowed to declare a new checked exception, how it would be handled? We are trying to catch a BatteryException, but the overriding method declares that it throws an EngineException. So, at runtime, the overriding method may throw an EngineException, and we were supposed to handle or declare a BatteryException.

That's the reason why we are allowed to declare just the same checked exception or a subclass of it, since the subclass exception could be handled by a superclass exception, like in the following example:

Now, when calling car.start() at line 1, since the car variable is of type Vehicle, we need to handle or declare the VehicleException, as declared in the start() method of the Vehicle class. At runtime, the method start() will be overridden, because the object is of type Car, and the method start() of the Car class declares that it throws an EngineException, but an EngineException is a subclass of VehicleException, so the catch at line 2 is ok.
 
shambhavi sham
Ranch Hand
Posts: 136
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you so much !     

but you didn't answer question  3. why a subclass is allowed to declare a new unchecked exception that is not declared its parent class ?
 
João Victor Gomes
Ranch Hand
Posts: 110
11
Eclipse IDE Java Netbeans IDE Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
shambhavi sham wrote:but you didn't answer question  3. why a subclass is allowed to declare a new unchecked exception that is not declared its parent class ?


Because you are not required to handle or declare an unchecked exception. It doesn't depend on whether you handle/declare it or not, since a RuntimeException is an internal problem.
As its name says, a RuntimeException occurs when something goes wrong at runtime, and since it isn't required to be predicted at compile time, it will not give you a conflict of exceptions like in my previous example.
Also, you are allowed to throw a RuntimeException (and any of its subclasses) without declaring it in the method signature.

With that being said, let's see some examples:

At line 1, we are declaring an IllegalArgumentException, and an IllegalArgumentException is a RuntimeException. In fact, if we don't declare it in the method signature, it is still ok. The exception would be thrown anyway. If we are not required to handle a RuntimeException in the caller, there is no need to declare it in the source either.
At line 2, we are calling the method play(Song song) from the Instrument class, but at runtime, it will be overridden because the type of the object is Guitar. Since we aren't required to handle it, there is no conflict, and if that exception occurs, it will be thrown normally at runtime.
So, remember, unchecked exceptions (RuntimeException and its subclasses) are not required to be handled or declared. They are meant to be thrown at runtime when something goes wrong internally in the program, hence, doesn't matter if a method in the subclass throws a new RuntimeException, because it will be thrown at runtime, and we don't need to anticipate it.
If you try to handle an unchecked exception, if the method you are calling throws that exception, your catch block will catch it. If you don't try to handle it, a stack trace of the exception will be printed and the execution stops.
 
shambhavi sham
Ranch Hand
Posts: 136
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks a lot ! 
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!