Java Exceptions – DZone Java

Java Exception

Java Exceptions are classes created to handle exceptional application behavior. In this article, I explain how to use the Java Exception class and how to create an Exception structure with the existing Java Exceptions design in mind. The Concept of Java exceptions is one of the key milestones in Java, and every developer must understand it.

Java exception structures are more useful than you might think

The structure of Java exceptions is very useful in telling the developer a set of important things (if the developer uses it correctly). So, here, you can see the basic structure:The main parent class that can catch all possible situations is Throwable, which has two subclasses: Error and Exception.

Java Error

Java Error stands for exception. Once an error occurs, the application may be shut down.

Java Exception

Unlike errors, Java exceptions have the opportunity to recover an application from a problem and try to keep the application running. Exceptions also fall into two categories:Exceptions are represented by run-time and non-run-time exceptions, also known as checked exceptions. This classification is very similar to error exceptions, but in this classification checked exceptions are more optimistic in terms of recovery.

Checked and unchecked exceptions

In Java, there are two types of exceptions. Checked exceptions force developers to create handler exceptions or rethrow them. If a checked exception is rethrown, the Java function must declare it in its signature. The unchecked exception does not require any action. This design means that unchecked exceptions cannot be handled and are destined to be thrown into the top-level parent class.

Error investigation

There are two ways to handle a thrown exception: handle it in the current method or just rethrow it. There is no better way: you might have a parent handler or handle it in some way, such as creating retry logic.

Good, bad and ugly

With this introduction, we can classify all exceptions into three groups: Checked, Runtime, and Error. The main idea is that each of them will fall into a different situation. The most optimistic are the Checked exceptions. The runtime will be in a situation where there is little chance of recovery. And the most pessimistic is Error.

Checked, Runtime, Error … And then what?

Knowing the types of exception classes, we might be able to answer the next question:

  • How bad it is and what the cause of the problem is.
  • How to solve this problem.
  • Do we need to restart the JVM?
  • Do we need to rewrite the code?

Knowing the exception class, we can predict what might go wrong. Considering the underlying causes, we can hypothesize what the cause of the problem is and how to solve it. Let’s review the most popular scenarios to see what these exceptions can tell us. In the following paragraphs, we’ll review famous exceptions and investigate what the underlying code is. In our investigation, we assumed that the application was stable and that the development phase had been completed and tested.

Error investigation

Let’s start with the most pessimistic case or our ugly man. Is Error really that ugly? Let’s take a look at the most common Java errors:So, in most cases, all you need to do is change the JVM configuration or add missing dependencies. There will still be cases where you need to change your code, but they are unlikely to apply the change in every case.

Checked anomaly survey

For checked exceptions, we expect to have the opportunity to recover the problem; For example, try again. In this section, we review the most famous checked exceptions. The exceptions provided may be each other’s superclasses, but, here, I’ll just list the most common cases and not care about their relationships:Well, there are a lot of exceptions, but, as PROMISED, I’ve put the most common ones here. So, what does this chart show? If we look at the most likely causes, we’ll see that most of them not only don’t require any code changes, but don’t even require a restart of the application. So, obviously, it’s the good guys.

Runtime exception investigation

The most common and personally pessimistic exception: runtime. Checked and Error Exceptions Errors do not cause any code changes. In most cases, however, runtime exceptions highlight real problems in your code that can’t be fixed without rewriting the code. Let’s find out why by looking at the most popular runtime exceptions:One example might give the impression that any runtime exception will cause the application to fail. In most cases, this is true, because the application cannot be restored without changing the code. Ultimately, run-time exceptions are our bad guys, leading to new code changes, developer stress, and lost business.

Some critics

During this review, we made one big assumption: that the code was ready for production and fully tested. In practice, however, this is difficult to achieve. So, the conclusions we make are not 100% reliable, but the more stable the code, the truer the results.

Checked for exceptions and code contamination

Based on checked exceptions, the design developer must make all recoverable exceptions checkable. Therefore, each call to a method with a checked exception signature adds 3-4 lines to the Try Catch structure. This approach makes the code ugly and less readable. Personally, I prefer to use runtime exceptions. Even in the case of the design library, you can still keep runtime exceptions in the method signature and add some comments to the API. In that case, your API users will be able to decide how to handle it.