Some suggestions and suggestions for beginners of Java Design and Development (2)

Author: Xiaoxia from: csdn

【Handle your exceptions]

Exception Handling is an important part of Java programming. It is recommended that you read or.

Below are some suggestions from the book:
* Never ignore exceptions.
* Do not hide exceptions.
* Exception only when abnormal
* You can check for recoverable usage exceptions.ProgramRuntimeexception)
* Document the exceptions caused by methods
* The detailed information includes the failure capture information.
* Use finally to avoid resource leakage
*....

It is particularly pointed out that null should be specially handled during development. Otherwise, nullpointexception exceptions are often thrown, which is the most troublesome exception in Java.
If your program reports dozens of nullpointexception due to a null value, it is not only annoying, but also difficult to locate the error. Therefore, you must pay attention to this issue in Java.
If your function does not allow a null value, you can intercept it, throw an exception, or give the customer a more friendly prompt. Isn't that good?

Let's take an example:

Public String getname (User auser)
{< br> // What happens if auser is null
return auser. getname ();
}< br>
obviously, if the parameter is null, an exception is thrown. Should be changed to:
Public String getname (User auser)
{< br> If (null = auser)
{< br> return "";
}< br> else
{< br> return auser. getname ();
}< BR >}< br>
or you require that the parameter cannot be null. You can also throw an exception to force the user to enter a null value.
the difference between runtimeexception and common exception is often ignored. in Java, this is a special exception class. If this exception is encountered in a program, the user can not intercept it, and if it is another common exception, it is not allowed to intercept it. Our Code is often written as follows:
try
{< br> // your code here
}< br> catch (exception E)
{< br> // do warn
}

In this way, all exceptions are intercepted, including runtimeexception. In many cases, this is not an appropriate processing method. We should only intercept the necessary exceptions and ignore runtimeexception.

For runtimeexception, there is a better way to use it in spring. We recommend that you read the exception handling code in the Spring framework in transactions, such as the sqlexception conversion thrown by JDBC.

For Exception Handling, I suggest the following:
* When an exception is caught and thrown again, the original exception information must be included.
* Do not forget runtimeexception. Unless necessary, do not catch all exceptions in catch (exception e) mode.
* Do not use exceptions for process control. The performance of exceptions is expensive. (Some may disagree with this. I will not discuss it in detail here)
* Do not throw exception handling to others. If this function is capable of processing, do not throw the exception.

It is recommended that you read in detail or.

【Excessive dependency]

When Locating errors, I often find that I have browsed seven or eight files, but I still haven't found any place to execute the actually needed functions. This is very depressing. A calls B, B calls C, and C calls d ...... People cannot find the North

In the face of such a program, the problem is not only the trouble of locating errors. If you need to maintain such a function library/framework, I am afraid you have a very high level of control capabilities, otherwise, I will not maintain it.

We 'd better not write such a program for people.

【Abuse Interface]

currently, interface programming is popular. This is inherently good, But interface abuse often occurs.
"interface-oriented", so all classes have a corresponding interface. The function declaration of the interface is the same as that of the class, and one interface has only one class to implement it. What is the significance of this interface? (Except for transactions using spring)
according to law of demter, an object should have as little knowledge as possible about other objects. Only the methods required by the other party should be defined in an interface, rather than some useless method declarations in the interface.
example:
public class mycounter
{< br> private int N1;
private int N2;
Public mycounter (INT N1, int N2)
{< br> This. N1 = N1;
This. N2 = n2;
}< br>
Public void setn1 (INT N1)
{< br> return this. n1 = N1;
}< br> Public void setn2 (INT N2)
{< br> return this. n2 = n2;
}< br> Public int getn1 ()
{< br> return N1;
}< br> Public int getn2 ()
{< br> return N2;
}< br>
Public int getresult ()
{< br> return N1 + N2;
}< BR >}

we can see that the main purpose of this class is to obtain the calculation result, so the correct interface should be similar:
Public interface counter
{< br> int getresult ();
}< br>
but in many cases, this interface is often used:
Public interface counter
{< br> int getresult ();
int getn1 ();
int getn2 ();
void setn1 (INT N1);
void setn2 (INT N2 );
}< br>
there are two consequences for doing so:
1. except getresult, other functions are useless, so they are redundant.
2. If we want to implement a counter by ourselves, if the interface only defines getresult, we only need to implement it. Our own classes may be multi-number operations, multiplication, division, addition, subtraction, and other operations, and parameters may also be arrays. However, if you declare an interface using the second method, we must implement the following four methods. If so, it is not only useless but a waste of time. I'm afraid we're going to yell at our mother.
therefore, the interface has a good effect, but do not abuse it.
■ if your interface always has only one class implementation, there may be no need to use the interface.
■ your interface only needs to declare functions used by others.