• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why compiler compels only checked exception to be put in try catch clause not RuntimeException  RSS feed

 
RabiDas Sharma
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,

what is the use of checked exception.
I know unchecked exception or Runtime exception are thrown by jvm whenever
programmer makes any mistake in logic and current thread is terminated.

But checked Exception are checked at compile time so that compiler compels
programmer to put risky methods in try catch clause. And this checked Exception
are caused due to problem in IO operation or any such operation which the programmer
can't control.Programmer can't do anything to avoid this checked exception but can
catch this exception.


Now the question is Why compiler compels checked exception to be put in try
catch clause but doesn't complain anything in case of Runtime Exception???



thanks in advance
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
RabiDas Sharma wrote:...I know unchecked exception or Runtime exception are thrown by jvm whenever
programmer makes any mistake in logic and current thread is terminated.

But checked Exception are checked at compile time so that compiler compels
programmer to put risky methods in try catch clause. ... Programmer can't do anything to avoid this checked exception but can
catch this exception.


I think you have that wrong. The reason for checked exceptions is because it takes circumstances that a programmer must consider and have plans for, and forces them to consider and have a plan (at least by handling the exception). Checked exceptions are for situations that are out of the programmer's control must must be considered for a stable implementation. For example, any system which writes to a disk has to consider what to do when the disk is full. The happy path (inside the try {} block) naively assumes there is space and permissions to write, but the fall back plan (the catch (...) {} block) handles when there is no disk space, or the file is used by another processes or the app doesn't have permissions to write to it. These things are what you must consider to have a well-implemented system that writes to disk, and since you have to catch the IOException you have a place dedicated to handling those things.

Runtime Exceptions, on the other hand, are caused by mistakes by the programmer. They aren't really part of something you should expect when writing an application. You might be able to deal with them, so you can write catch blocks for them, but you might not be able to, so the catch blocks aren't required. But they should be avoided through good programming practices, rather than worked around via catch blocks.
 
Heena Agarwal
Ranch Hand
Posts: 262
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
RabiDas Sharma wrote:Hi everyone,

what is the use of checked exception.
I know unchecked exception or Runtime exception are thrown by jvm whenever
programmer makes any mistake in logic and current thread is terminated.


All Exceptions ( including RuntimeExceptions ) are thrown by the JVM when a condition that signals them is satisfied. All happen at run time.
The compiler just enforces that the programmer follow the handle or declare rule for the checked exception.
That requirement does not apply to the RuntimeException(s).

All Exceptions ( including RuntimeExceptions ) if uncaught are passed on to the caller. And the caller of the public static void main(String[] args) method is the JVM.
So in the end, all the exceptions can cause your application to break at runtime.
The word RuntimeException is very misleading. All Exceptions happen at run time.

RabiDas Sharma wrote:
But checked Exception are checked at compile time so that compiler compels
programmer to put risky methods in try catch clause. And this checked Exception
are caused due to problem in IO operation or any such operation which the programmer
can't control.Programmer can't do anything to avoid this checked exception but can
catch this exception.

All checked exceptions are not caused by IO operations, but yes that is one of the case. Checked exceptions bind the programmer to handle or declare such cases. Programmers can catch the exception and in the catch block they can have any logic based on the type of exception they are dealing with and the other run time conditions. InterruptedException is an excellent example of a checked exception that you may wish to catch and handle or catch and ignore.
 
Heena Agarwal
Ranch Hand
Posts: 262
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm sorry I am coming back to this thread again. I was (slow) processing what has been said. I was also relating it with the way the classes in rt.jar handle exceptions. This helped me understand your response better.

I have one scenario however that confuses me. Since this is in line with the current topic, I thought of posting it here. I hope the OP wouldn't think I'm trying to steal his/her topic. Ok, the scenario is the same as what I had posted in this thread but I have a better explanation this time. So it's not going to be so vague.

So let us say my application expects the user to upload a file. Now this file may/may not have a header record. My application is supposed to find out if this file contains a header record. If it does not contain a header, let us say processing x is invoked. If it contains a header, then I can have various types of headers but all kinds of headers have at least a few common mandatory header columns. So if the file contains a header and does not contain these mandatory columns, my application is supposed to display a message to the user and ask him to upload another file again.

So now we come to the part of parsing the header record. Obviously it will be a lower level API that would do that part. Now after I know the header is invalid, I should have the method call stack unwind. If my lower level API threw a ( custom or not ) RuntimeException in this case, would it be a justified case of RuntimeException? But if I had used a checked exception in the lower level API, the lower level API would have to have a throws clause for that exception. Ok, that exception would be well understood in the lower level API. But the higher level API might not know how to handle it. But another part of my reasoning says that if my lower level API only deals with processing the header record of a file, invalid header is a justified case of a checked exception for that API. What would you say?

What I did was I created a RuntimeException that was thrown by the lower level API. I also put the throws clause for that exception in the lower level API method. In the higher level API, I put that piece of code that could throw that exception in a try block and provided a catch block. This catch block would throw a custom checked exception that the higher level API understood and it would wrap the RuntimeException. I am now not sure whether wrapping of that RuntimeException in a checked exception was the right thing to do. If my application expects the user to upload the file again, does that mean the situation is recoverable and hence the use of a checked exception in the higher level API is justified? But I didn't across such a scenario in rt.jar classes. Not that I looked at it extensively, but what should have been a better design?

Any suggestions?

 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Heena Agarwal wrote:I hope the OP wouldn't think I'm trying to steal his/her topic.

Me too, which is why I answered this post in your other thread. Let's keep this one on topic.

Winston
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!