Introduction of Exception Handling in Java

The main issue everyone find with the exception handling mechanism is to when to use the same and how. Let us together by the means of this article try to see what the best ways available for exception handling are. The idea of the all the programmers like us is to come up with a quality code that instead of making the problems worst, resolves the same at the earliest. But the worst part is that, our code often faces the issue of exceptions.

No one in the world being a programmer likes to come across these sorts of exceptions as a harmful product to the code. So we have to find the solution in order to avoid the same. Let us see one of the simple examples that the programmers often use so as to avoid the exception.

public void ForgetAllExceptions(){
    try {
        enter some code that can cause exceptions
    } catch (Exception ex){
        ex.printStacktrace();
    }
}

What is wrong with the code above?

Once an exception is thrown, normal program execution is suspended and control is transferred to the catch block. The catch block catches the exception and just suppresses it. Execution of the program continues after the catch block, as if nothing had happened.

What will you say about the below code?

public void Method() throws Exception{
}

If you see there is no code in the method, it is blank. Nowhere in the world can any code with no method in it throw any sort of exception. Java will never ever stop block you in doing the same. Exception really needs to be controlled else it will make your code to run at a snail’s pace. This is because exceptions are famous for consuming your machine’s memory and also the CPU utilization so as to generate, throw as well as catching the exceptions. Excessive use of the same i.e. if not handled timely, these exceptions can make it really hard for the programmers even to read out the code.

The Exceptions Behaviour:

Generally speaking, being a programmer, you can come across the following situations that can lead to the presence of the exception:

• Condition 1: Errors in programming that can lead to exception: Here we will come across the condition where errors in programming can lead to the exception.

For example: Look at this code: NullPointerException and IllegalArgumentException. Error in programming can at times is not possible to be handled by the client code as well.

• Condition 2: Errors in Client code that can lead to Exceptions: You may come across some client code that is not designed to be supported by the API thereby doing something that is not allowed to do so. Some other means can be adopted in case you get to see anything useful hidden in the exception. Say for instance an exception is thrown at the moment of parsing an XML doc and the one that is not well documented. Such sort of exception can contain vital details pertaining to the location in the XML doc that has lead to the issue. Resolution can be found out taking into account the details captured from the exception.
• Condition 3: Resource breakdown is also the reason for Exceptions: These are generally the exceptions that take place on failure of the resources. Say for example, there may be a failure in the connection of the network. The other reason could be that system runs out of memory. Allow some time for the client to re-run the execution again else you would require to stop the application completely till the time this issue is not resolved.

Two sorts of exceptions are classified by Java:

• Checked exceptions
• Unchecked Exceptions

Checked Exceptions are inherited from the class known as “Exception class”. As far as managing these sorts of exceptions are concerned, it is done in a catch block. The other way could be transmitting it using the throws clause.

And then we have the unchecked exception category, where in we don’t see any need for the client code to deal with them.

NullPointerException Hierarchy:





Figure 1: NullPointerException Hierarchy

From the above diagram, we see that NullPointerException broad out from RuntimeException . So this is an unchecked exception.

There has been a lot of debate around which exception to use more whether checked exception or unchecked exception. At times we tend to see loads of checked exceptions in use and not much of unchecked exceptions .If we talk about the java community, there is quite a lot of uncertainty pertaining to check exceptions as well as its actual value. The prime reason for this argument is that that Java gives the impression to be the primary mainstream Object Oriented language with checked exceptions. All exceptions of C++ and C# fall in unchecked exceptions category.

There is a compulsory agreement on the invoking layer to catch or throw it for the exceptions particularly the check exception by a lower layer. The checked exception indenture linking the API and its client quickly modifies into an unnecessary burden if the client code is incapable to manage the exception successfully. Programmers of the client code possibly will commence taking shorter route by restraining the exception in a blank catch block or merely throwing it a thereby inserting the load on the client's invoker.

Consider the following example where the code displays violating encapsulations.

public List CaptureFileRecords() throws
   RecordsNotFoundException, SQLException{
    ...
}

The method CaptureFileRecords() throws two checked exceptions- The client of this process has to unambiguously pact with the execution-definite exceptions, yet if it has no plan what file or database call has abortive inside CaptureFileRecords(), or has no trade offering filesystem or database logic.