Java Exception Design

Classification structure diagram of the exception

• What is the exception mechanism for solving problems?

It is also a way to end a thread, from a certain point of view, it is no different from normal return, but an abnormal way to end. So why do you need this kind of anomaly mechanism? The anomaly mechanism itself is also divided into severity, such as: Error/exception. It takes a form that does not invade the normal process code, tries to keep the program from crashing (the error type of exception), and gives the developer a friendly hint (convenient location for the problem).

• What are the scenarios in which the various anomalies occur? Can you handle it?

Error errors

This exception is usually a program-level error that directly causes the program to crash.

Common exceptions are: Virtualmachineerror (JVM error), Awterror, OutOfMemoryError (heap memory overflow), Stackoverflowerror (stack memory overflow), Noclassdeffounderror, Nosuchmethoderror.

This error is usually not handled by the program itself, it needs to be optimized for the JVM, such as parameter size setting, dependency packet Introduction, etc.

RuntimeException Run-time exception

This exception is usually the exception that occurs during the process of running the program. Either a bug or a parameter error, and all of these anomalies are not expected at the time of coding. Causes the invocation of a single method to end directly.

Common exceptions are: illegalargumentexception (illegal parameter exception), Illegalaccessexception (illegal access), ClassCastException (type conversion exception), Indexoutofboundsexception (Boundary exception), numberformatexception (numeric format exception).

Run-time exceptions are usually caused by an incoming parameter error or a program bug that requires the user or the developer to modify the issue based on the prompt information.

Checkedexception Check Type exception

A non-runtime exception is a defined exception that is displayed at encoding time, which must either be caught (try catch) or thrown (throws), otherwise the compilation cannot pass.

Common exceptions are: IOException (IO exceptions, such as: SocketException network exception, file stream exception), SQLException (SQL Exception).

A check-type exception, usually a predictable anomaly, is a remedial measure that is performed at the time of encoding.

• What do you do to design an exception?

Design according to the type of exception

An exception of the error type, which is usually a system-level issue. Unless we are going to terminate the whole process, we will not generally be involved in this kind of exception design;

Checkedexception Check-type exceptions, which belong to the application encoding level. It belongs to an alternative means, such as: Socketexception/fileexception, after capture, can be further remedied. I think it belongs to an alternative programming idea.

RuntimeException run-time exception, which is a request-level/one-time method call issue. In the process of processing, there will always be an ill-conceived problem. For example: the user passed in the wrong parameters, the developer's bug; This usually aborts the request or method call, returns the error message, and then resolves it by the corresponding person.

According to the principle of who caused the problem who will solve

The cause of the exception is two things: the customer and the developer.

This system-level error occurs when our application has insufficient memory or disk space or system downtime. It can only be solved by OPS or the developer, which is not visible to the customer and does not care.

When we apply a fragment code in a method, because of the developer's negligence, rather than the bug caused. This problem can only be solved by the developer, not visible to the customer, and not concerned.

When a customer calls a method, the passed parameter is incorrect or the data is incorrect, the problem can only be solved by the customer, and the developer only needs friendly hints to the customer.

• Examples of design anomalies

/** *  the exception that occurred with the program bug. For developers to locate the problem . *  @author  yangyc */public class  Appexception extends runtimeexception{    public appexception (String  Message, throwable cause)  {        super (message,  Cause);    }}/** *  a suggestive exception. Resolved by the caller. If the argument is empty, the parameter is malformed, the data is not retrieved, etc. . *  @author  yangyc */public class PromptException extends RuntimeException {     public promptexception (String message, throwable cause)  {         super (message, cause);     }}/** *   Remote invocation of the service exception. This is a problem that can be expected during the coding period . *  @author  yangyc */public class rpcexception  extends exception {    public rpcexception (String message,  Throwable cause)  {         super (message, cause);     }} 

• Using exception Tricks

1. When do I use a check-type exception or a run-time exception?

If the anomaly is foreseeable or can be remedied, the robustness of the program is enhanced from the coding angle by using the check-type anomaly. On the contrary, there is a problem that must be aborted, with runtime exceptions.

2. When are exceptions captured?

Usually in the call start capture or AOP of the higher level of uniform processing, not to capture; The problem is clearly known and can be handled for such exceptions, and this type of exception, which is usually converted to an exception, continues to be thrown upwards.

3. What should the content of the try catch be when the exception is captured?

It is generally inappropriate to take the captured code too long, which can affect the complexity of the exception handling mechanism, and you should also consider putting tight code together to ensure the readability of your code.

4. Abnormal conversions

Sometimes, after catching an exception, a new exception is thrown and continues to be processed by the subsequent program. At this point, you need to convert the exception. For example, to convert a check-type exception to a run-time exception.

5. Abnormal delivery

When an exception conversion occurs, be aware that the original exception information is not lost. This method should be used with the new Xxxexception (MSG, E).

6. Throw exceptions early, catch exceptions late, and explicitly throw exception types

7. After catching an exception, do not ignore the exception

public void Donotignoreexceptions () {try {//do something} catch (NumberFormatException e) {//thi s'll never happen}}

8. Do not capture Throwable

Throwable is the parent of all exceptions (Exception) and errors (error), although it can be used in catch clauses, but never! If you use throwable in a catch clause, it will not only catch all exceptions, it will also catch all errors, which are thrown by the JVM to indicate a serious error that is not intended for the application to handle. OutOfMemoryError and Stackoverflowerror are typical examples, because they are caused by situations beyond the scope of application processing.

Https://www.cnblogs.com/beatIteWeNerverGiveUp/p/5915255.html

Java Exception Design