java-exception-handling-class-hierarchy-diagram

exception handling in java interview questions

Everyone knows that exceptions are something you avoid or handle. In the world of Java, this means that we should not use checked exceptions, and must document all potential exceptions.

Well, even though the golden rule for handling exceptions is to not ignore them, the fact remains that in your code there may be unhandled exceptions.

exception handling in java interview questions

You might ask – Why? Well, there could be a lot of reason why things go wrong – from network issues to server disconnection; from hardware failure to file unavailability; from incorrect user inputs to any number of other things.

We will discuss various interviewer questions on exception handling in Java which will help you crack your next interview:

Why do we need to use try-catch in Java?

Java, like other programming languages, uses exceptions to signal errors and other conditions that cause a program to terminate abnormally.

By default, exceptions are not handled and the program will terminate when they occur. You can use exceptions to signal error conditions, but you have to explicitly handle them using try-catch blocks.

There are four major reasons why Java programmers are encouraged to use try-catch blocks: You can’t predict when an exception will occur in your code.

The user can type something you didn’t expect and cause an exception. External systems can go offline or return unexpected data that causes an exception.

Unhandled exceptions can cause your program to terminate abruptly. Exceptions are part of the language. You don’t want your program to stop as soon as an exception occurs.

You want it to continue running, but with an indication that something went wrong. You can’t see the stack trace of an exception if it’s immediately killing your program.

You don’t want your program to stop as soon as an exception occurs. You want it to continue running, but with an indication that something went wrong. You can’t see the stack trace of an exception if it’s immediately killing your program.

What is the difference between a Checked Exception and an Unchecked Exception in Java?

Checked Exceptions are those that are expected and can be handled by the programmer. For example, if you try to open a file, and the file does not exist, then the FileNotFoundException is thrown.

This exception is checked because you can handle it in your code by providing an alternative path for opening the file.

If, on the other hand, you try to open a file and exceed your user’s quota, then the corresponding IOException is thrown, which is an unchecked exception because you cannot handle it in your code.

Checked vs. unchecked exceptions are the way Java programs notify you about mistakes you make when you use the built-in Java API.

When something goes wrong, and an exception is raised, it is one of these two types of exceptions. Whenever possible, you should anticipate these exceptions and catch them as early as you can.

When you catch an exception, you have a chance to fix the problem or provide a helpful message to the user. If you don’t catch an exception, it will crash your program and display a generic error message that doesn’t give any details about the problem.

There are two categories of exceptions: checked and unchecked. Checked exceptions are those that the programmer knows will occur, and can be handled at the time the code is written.

For example, in an application that queries a database for data, if the database is unavailable, an exception is thrown, and you as the programmer can anticipate this and handle it accordingly.

Unchecked exceptions are those that the programmer cannot predict, and usually indicate an action that is outside of the application’s control.

For example, if you try to open a file whose name exceeds the maximum length specified in the operating system, an exception is thrown, and you have no control over this.

Which exceptions must you handle and which should you let pass through?

If you’re writing code that calls other libraries, you can’t handle all exceptions. Handling exceptions requires extra code that takes time and resources, and it can be difficult to determine when an exception is worth handling.

Letting exceptions pass through your code unhandled is not a good idea either, since it leads to a bad user experience. Consider an application that repeatedly asks for an invalid username.

The user will eventually figure out that he entered an incorrect username, but not before he has been frustrated many times. A better practice is to handle the exceptions, and inform the user about the problem.

In order to decide which exceptions to handle and which to let pass, consider the following:

– Exceptions pertaining to user-generated data like incorrect username, password etc. should be handled. – Exceptions pertaining to network issues like server disconnection, network timeout, or server error should be handled.

– Exceptions pertaining to hardware issues like disk out of space, or hardware failure should be handled. – Exceptions pertaining to software issues like incorrect file permissions, incorrect file format should be handled.

How to decide whether to use finally or throw in a try-catch block?

A finally block always executes, whether or not an exception is thrown. This means that you can use it to guarantee that some resource is always closed, or some computation is always completed.

If you want to guarantee that a try-catch block is executed, regardless of whether an exception is thrown, you should use a finally block.

If you want to guarantee that a try-catch block is executed, regardless of whether an exception is thrown, you should use a finally block.

A finally block is useful when you want to perform some action regardless of whether an exception is thrown. For example, you may want to close a file that you opened in the try block.

A try-catch block is useful when you want to catch an exception and perform some action, or when you want to let an exception pass through your code unhandled.

When should you use an assertion check vs. an exception handling block?

Assertions will cause your application to terminate when executed, and are useful for debugging purposes. For example, you may write an assertion check to validate that a file exists before trying to open it.

Exceptions, on the other hand, are used to signal errors and other conditions that cause a program to terminate abruptly. Assertions are a debugging feature that helps you identify problems in your code.

Exceptions are used to signal errors that cause your code to terminate. Assertions are used to verify whether your expectations with respect to application behaviour match the actual behaviour of your application. Exceptions are used to signal errors that cause your application to terminate abruptly.

Conclusion

There are many ways to skin a cat, and there are many ways to approach exception handling. It is important that you pick the method that makes the most sense to you, and that you understand its implications.

As a developer, you should understand that exceptions are part of the language. You cannot ignore them, but you cannot let them stop your program.

You must handle them gracefully and display a helpful message to the user. You must decide which exceptions are expected, and which are unexpected.

Add a Comment

Your email address will not be published. Required fields are marked *