Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

why Throws to main method

 
kedar parundekar
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
/*code :------------------->*/

class DemoExcep2
{
int a,b,res;
public void disp() throws Exception
{
a=10;
b=0;
res=a/b;
System.out.println(res);
}

public static void main(String[] args)
{

DemoExcep2 obj =new DemoExcep2();
obj.disp();



}
}
/**************************************/
Q > if i run above program then I have Compile time error

DemoExcep2.java:15: unreported exception java.lang.Exception; must be caught or
declared to be thrown
obj.disp();

Why ?
^
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because you're calling disp() which throws an Exception. This is a checked exception which have to either catch, or rethrow.
You could add a try/catch block into your main method.
 
Ellie Barnes
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because your method throws an exception, that exception must be dealt with by the calling method (in this case your main method). I'm not really sure what you want to do with this method, so this will just print you the error message associated with the exception:


 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15359
39
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Java Tutorial on Sun's website explains exactly what exceptions are, how to use them and what the difference between checked and unchecked exceptions is.

Handling Errors Using Exceptions

You are required to handle checked exceptions with a try / catch or throw them on to the calling method.
 
Kaush Kane
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have one general question on this topic.
Normally it is said that the code which is likely to throw exception shuould be inside the try block.

The question I have is: In case of Java Runtime Exceptions it is not possible everytime to know which part of code wud throw an exception. In such case how to decide that which part of the code shud be in try block.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's a tough one. For example you can get NullPointer almost anywhere but you wouldn't wrap every method call in a try-catch block.

I wrote a little web server with a method at the top of the call stack that attempts to catch and display everything. If the server can survive the error, it goes on running. If it can't, well, it can't and we haven't lost much in trying.
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If this is just a bit of test code, I find it slightly easier to have the main throw an exception. YMMV:
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kaush Kane:
I have one general question on this topic.
Normally it is said that the code which is likely to throw exception shuould be inside the try block.

The question I have is: In case of Java Runtime Exceptions it is not possible everytime to know which part of code wud throw an exception. In such case how to decide that which part of the code shud be in try block.


That's only partially true. Exceptions a method may throw should be documented regardless of whether or not they are checked or unchecked. If you and your colleagues do this then all that is needed to find out what can be thrown is a check of the documentation. In that scenario it's purely a matter of whether or not you want to handle the exception there. If you can handle it and want to handle it there, then do so. If you can guarantee the exception will never occur that's antoher option. If you do want to handle it, then handle it.

Working with legacy code or APIs outside of your control is much more difficult if the developer did not document exceptions well. In that case I'm not sure there's much you can do except deal with it on a case by case basis. As Stan alluded to some type of safety net to catch anything that slips through which should not take down the entire application is also a good idea. Hopefully it never reaches that point, but better to have the problem logged for you to deal with than to have the entire application die for something trivial.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic