deepak carter wrote:
we can do it but we should not do it.Can you explain me why we should not do it.
1. Catching Exception includes RuntimeException and all its descendants. We usually don't want to catch those, as they indicate a bug in our code and therefore are not something we should try to recover from.
2. Even without the above, catching Exception can be too general. Do we really want to handle every kind of error condition the same way?
3. Catching Exception can hide future changes from us. Let's say the code in the try block can throw IOException. We catch Exception and handle it. That takes care of IOException for us. Now let's say we upgrade a library that the try block is using. The new version can now also throw SQLException. Unfortunately, since we are catching Exception, that covers SQLException also, and we don't get a compile-time error. You might think this is a good thing, but your mistaken. It's better to get that compile-time error so that we're forced to look at our exception handling and add approriate handling for SQLException. Without the compiler error, we might not have noticed that there's a new exception that wasn't being thrown before.
and second question is why exception are throw i mean to say
suppose we create a servlet in that we write doget method like this
i mean to say why we are throwing ServletException....which thing is causing to throw ServletException
Different layers or modules usually define a base exception class that covers all the exceptions that can be thrown by that layer or module, and then they add more specific subclasses for the different kinds of things that can go wrong. This is about separation of responsibility.
So when implementing a Servlet, the designers decided that its methods could throw ServletException, or any of its subclasses. If I'm a framework calling a Servlet's doPost() method, I don't need to know that deep down an IOException or SQLException occured. All I care about is that something went wrong with the Servlet. That doPost() might directly throw a ServletException or a subclass if something goes wrong during its execution, or it might wrap an IOException in a ServletException. This way the caller only has to deal with layer-appropriate exceptions, but still has access to the underlying cause if desired.
Most of the time, you should catch the specific exception and wrap your custom exception around it and re-throw it. I, generally, let the exception propagate to the root level and the root level I do whatever I need to do specific to that exception.
They could have done that. However, the designers decided that it would be a good idea to allow those methods to report failures via the standard exception mechanism. That's why it exists, after all. If those methods weren't allowed to throw any checked exceptions, then if something went wrong, they'd have to either throw an unchecked exception (which don't have to be documented and the caller wouldn't know what kinds of errors to expect) or return an error code (which is icky and avoiding that is the whole reason the exception mechanism exists in the first place).
Declaring that you throw a particular set of exceptions is generally a good thing. It's a formal way of telling your caller, "Here's what can go wrong, and here's how I'm going to tell you about it."
You have to keep in mind that the above is a compile-time error, while exceptions happen at runtime, when your code is being executed.
Now, when you compile this code, you're most likely doing so using a program that was written in Java. So parsing your file is part of the compiler's runtime. It may or may not use an exception to indicate that invalid token. I would imagine it does. But that's its internal concern. We don't need to know about that. All we care about is how it handles that exception--namely that it prints out a meaningful error message.