Question about throws

[Howard Ting]

As I understand, methods with throws clauses appended explicitly imply which type of exception may occur, but somehow I found it unnecessay to specify the type of exception because we can always use the class Exception as the class of the argument in the catch block and handle the exception problem very well. So why do we want to use the throws clause? Is there any better part of using it than not using it?
I really hope someone can help with my concept~

[C. Nimo]

'allo.
You got two things mixed up here.
1 - Methods that throw exceptions have that 'throws' clause. This states that this method might throw a non-runtime exception, and that alerts wrapping code (code that uses this method) that it should wrap the method call with a try..catch sequence.
If you ommit this 'throws' clause - you will not signal that an exception might be thrown outside the method. This, in the Java spec, says one of two things: you either never throw an exception from this method (i.e. all you do is very clean and simple) or -any exception that might be raised in this method will be handled inside the method itself (in try..catch).
2- Now, about the type of Exception - I agree that you could write 'throws Exception' and leave it all up to the wrapping code, but that's not very OO. When you use 'throws' you have a contract - and you want to follow this contract. Think of coding the other way around - suppose you have an existing code that uses your (unwritten yet) method, and checks for IllegalStateException.
Now, you write your method, and declare it as 'throws Exception' - The existing wrapping code will not compile now, because you said 'yeah, I can throw an IllegalStateException, but many others as well.'.
Helpful?
Nimo.

[Howard Ting]

Lots of thanks for your explanation~
I understand the first part completely - throws is just the "signal" informing the next programmer who uses the method whether the method may cause some kind of exception or not.
But for the second part, I guess it's another case from what I meant. I totally agree with your narration, but my opinion of the previous case is still not judged. My case was setting the class of the argument of the catch block to be Exception, as follows:
catch(Exception e) {...}
In this case, every kind of exception will be caught by this catch block. So there's no need to worry what kind of exception will occur. Isn't this a good way of avoiding the complication of enormous types of exceptions?
Please judge my presumption, thanks~

[Brian Pipa]

There are cases where that is fine - cases where it doens't matter WHAT exception occurred, there is only one path to take. Sometimes though - you will take different paths depending on which exception was thrown and in those cases you need to catch the specific exception(s) in order to know what to do next in the code.
Make sense?
brian

[Howard Ting]

Yes, you're right.
Perhaps it's like I myself asking for trouble, but I can catch any exception with the class Exception and then use the method getClass() to specify what exact exception it is, using if statement to handle different exceptions. Thus I only need one catch block.
But is this way more or less efficient? I don't know, just giving an alternative way of coding.
Thank you very much~

[Mani Ram]

Originally posted by Howard Ting:
but I can catch any exception with the class Exception and then use the method getClass() to specify what exact exception it is, using if statement to handle different exceptions. Thus I only need one catch block.

It is true that you need only one catch block this way, but you end up with multiple if-else blocks. Isn't it?
Look at the alternatives

try {
  //Some statements
}
catch (SQLException sqle) {
  //Handle SQLException here
}
catch (IOException ioe) {
  //Handle IOException here
}
catch (NumberFormatException nfe) {
  //Handle NumberFormatException here
}

try {
  //Some statements
}
catch (Exception e) {
  if(e.getClass().getName().equals("java.sql.SQLException")) {
  
//Handle SQLException here  
  
  }
  
  if(e.getClass().getName().equals("java.lang.IOException")) {
  
//Handle IOException here  
  
  }
  if(e.getClass().getName().equals("java.lang.NumberFormatException")) {
  
//Handle NumberFormatException here  

  }
}

Which looks cleaner & better? Also, in the first case the compiler complains you if you spell an exception name wrongly. But you won't get that assistance in the second approach.
For example, if you wrongly spell java.sql.SQLException as jav.sql.SQLexception, you won't get an error from compiler, and the exception won't be handled in runtime.

[Howard Ting]

Your elucidation and example really hit the nail on the head! I never thought of the problem of wrong spelling, which is the mistake I often make.
Much obliged~