Saturday, 28 March 2009

Playing with Exception Handling

This is the conversation between Guido and Pranali. Recently I saw the movie - Life is Beautiful. And Guido is the character from that movie. For now he is the friend of mine and going to discuss Exception handling with me. Yes, it appears to be very funny!! But why can't I use this name? So lets go ahead with the conversation. Those who feel I am crazy for them - Yes, I am!! :-)

Guido: Bongiorno Princepessa!!
me: :-)

Guido: Why have you kept mum since long? Why aren't you speaking anything about your technical journey which you started few days ago? You were reading something about exception handling in Java. Can you elaborate why does it exist in Java?
me: To handle risky behaviour of your code.

Guido: And What do you mean exactly by risky behaviour?
me: It is something like - "If we are not sure whether things will go as we want them to, then it's a risk. It is called exception in the world of programming.Any code can result into this unwanted behaviour. This is called risky behaviour.

Guido: OK, got. What do you do to handle this risky behaviour?
me: I make my compiler to examine some part of code carefully and if anything unwanted happens in that part, I make the compiler to catch the risk(exception) which is occurred.

Guido: Catch the risk? Is it some ball that you are making compiler to catch it? And who is throwing that?
me: For now consider it is an entity. My function is throwing it and compiler is catching it. My Compiler has very well fielders that it doesn't allow the exception to just run away after harming my application.

Guido: Wow!! Cricket? or Cops and thief? :P Jokes apart!! So you mean compiler will pick up the exception if it occurs. But then what will it do with that?
me: If that exception is handled in the same function itself, the handling part will be executed and rest of the functioning is continued.

Guido: What do you mean by handling?
me: Oh, handling is the mechanism to save the application after the exception occurred. You can say it is a set of some instructions those will be followed after the exception has occurred.

Guido: Interesting!! When thief steals something from you, you need to follow some steps to recover yourself from the harm occurred. Can we make this analogy here?
me: Yes Guido!! You are on the right track.

Guido: Great!! :-)
Now you said - "If that exception is handled in the same function itself, the handling part will be executed and rest of the functioning in continued." And if it is not handled in the same function, then?
me: Then the exception is thrown to the caller function. If it has the handling part, that will be executed. If not then again it will be given to the caller function. and so on...

Guido: ah, OK. Tell me, Can we compare it with the fielding of cricket? If the bowler(the function where exception occurs) can't catch the ball, then the fielder present at nearest peripheral part of it(caller function) will handle it. If he can't, the next peripheral fielder will handle it. And so on....
me: Exactly!!

Guido: Nah Nah!! Tell me first, if no fielder can handle it, then?
me: Then the ball goes out of the boundary!!

Guido: Please explain me technically now!!
me: Sure! See. Here, main() function acts like a fielder present at the boundary. If main() also doesn't handle it then the exception is not under the control of compiler. JVM will stop there itself.

Guido: OK. Got it!!
me: But Guido, remember whatever I told you about the journey of exception from function to the main function, it can happen only if every function on the way is throwing it. And every function on the way has to throw it, until exception is solved i.e. handled. Else compiler doesn't allow you to go ahead with the coding.

Guido: How Strict!!
me:It has to be. Otherwise your application will keep getting harmed with cruelty of risks.

Guido: Hmmm!! Right!!
So a function has to handle it or throw it. Right?
me:Yes! No function can keep the risk with it. To handle every risk, there are two options. Either you solve it or you just throw it. You can't live with the risk above your head. The same way function either handles it with the catch block or it just throws it. How logical it is!! This is also the principle of life. If you stay with the problem, you won't proceed further in life. If you throw it, you can delay the death. If you solve it, you can continue the happy living. Wow!!!!! I really love OOP for such analogies with the principles of life.

Guido: :-)
Now one more question!! There is a possibility that compiler wouldn't know whether exception will occur or not. e.g. If you have 2 variables a and b. You want to divide a by b. But the values of a and b are retrieved during run-time. While compiling how will the compiler know about it?
me: Well, this is called a runtime exception. You can throw them in your program, but compiler just ignores them. Hence they are also called unchecked exceptions.

Guido: A last question! Can we throw and handle multiple exceptions?
me: Yes. This is not analogous to cricket here. We can have multiple risk balls.

Guido: Still, La Vita e Bella!! :-)

No comments: