checked vs unchecked exception

[anish jain]

I have read that we make checked excpetions when we expect client to recover from that exception.

How would I know if client can handle the exception or not?

Could anybody please help me understanding this?

[Paul Sturrock]

You know this because you have though through what makes sense to the client, usually based on how the client can respond. If there is nothing the client can do you probably don't need a specific checked exception.

[Abhay Agarwal]

This can be deduced from Client business requirements

For eg - you are developing a website (Java Servlet based) for any client.
During design phase of project, we drill down client requirements and try to design the application according to client need.
Let us say that Client requirement is
-->

Require a page to show latest RSS Feeds from Yahoo News. In case Yahoo Feed is not available then use Google News Feed.

Now with this requirement in mind, we can design our Exception hierarchy.
So I will make following checked exception --> YahooFeedsNotFoundException (extends Exception)

Suppose I made a class (say - FetchFeed) which have two static methods - displayYahooFeeds() and displayGoogleFeeds()

displayYahooFeeds() method throws YahooFeedsNotFoundException exception when Yahoo Feeds are not available due to any reason (for eg - feed not available, network connectivity down, network time out, feed url incorrect etc)

Now i have another class (say - DisplayFeed) which one method - displayAppropriateFeed()

Sample code inside this displayAppropriateFeed() method can be

public String displayAppropriateFeed() throws Exception
{
    try
      {
            // call displayYahooFeeds method 
              FetchFeed.displayYahooFeeds();
      }
   catch (YahooFeedsNotFoundException yfnfexception)
     {
               FetchFeed.displayGoogleFeeds();
  
    }

}

Here, YahooFeedsNotFoundException is an checked exception because our application can overcome this error (error of not finding yahoo feed) by displaying Google Feeds instead.

I hope I have made my self clear and given you a basic understanding of statement -

we make checked excpetions when we expect client to recover from that exception

[Jesper de Jong]

It depends on the situation, it's hard to explain in general terms when you'd want to use a checked and when you'd want to use an unchecked exception.

Here's an example. Suppose you have some method that gets some data via a HTTP connection. It might happen that sometimes there is no network connection, so that the method cannot do its job. That's an example of an error that you might expect to happen, so you would throw a checked exception whenever that happens. The calling code could reasonably deal with the situation, for example by retrying the call later.

Example of using an unchecked exception: When somebody calls your method with invalid arguments, you might want to throw an IllegalArgumentException (which is an unchecked exception), because when somebody tries to do this it means that there is most likely a bug in the code that calls your method. In such a case you would not expect the calling code to be able to automatically deal with such a situation - it means there's a bug, and a programmer must look at it and fix it.

[Matthew Brown]

My general approach (which I think is similar to what Jesper is describing) would be: throw an unchecked exception for errors that are under the control of the client code, and checked exceptions for those that are not.

If the problem isn't under the control of the client - for example, if data is read from a database that might be unavailable, or a file being read that might not exist - then the client is going to have to cope with the situation. It isn't a matter of "can the client handle it" - the client is going to have to handle it if it happens, because there's nothing the client can do to prevent it. Handling it might involve showing an error message to the user, closing down gracefully, trying again, etc - we don't need to worry about the details. But the client has to do something, so I'll throw a checked exception to make them make a decision.

If the error only happens because there's a bug in the code (e.g. calling a method when the pre-conditions aren't met), then an unchecked exception is fine.