Valid Java notes (10)

List of related Reading Notes

Article 38th: Follow the universally accepted naming conventions

Java Naming Conventions fall into two categories: literal and syntax.
Literal naming conventions involve packages, classes, interfaces, methods, and domains.
The package name is hierarchical. Use periods to separate the first part. Each part must be at least 8 characters long and consist of lower-case letters and numbers (rare digits). Meaningful abbreviations are encouraged. In addition to Java and javax, it generally starts with a domain name, with top-level domain names placed at the beginning.
Class and interface names should have at least one or more words, and the first letter of each word should be capitalized (hump test). Try to avoid abbreviations.

The method and domain names follow the same literal conventions as the class and interface names, but the first letter must be in lowercase. A common field must contain uppercase letters, which are separated by underscores.

Syntax naming conventions are more flexible than literal conventions.

1. A class usually uses a noun or noun phrase, an interface or an adjective that is the same as a class or ends with "-able" or "-visible.
2. The method used to execute an action. A verb or verb phrase is often used,
3. For a boolean type method, a noun, adjective, or phrase is often added after the name starts with "is,
4. If the returned value is not Boolean, a noun or phrase is often used, or a verb phrase starting with "get.
5. If the class of a method is a bean, it must start with get.
6. If the class contains attribute operations, it is often named in setattribute or getattribute format.

Method for converting object types,

1. If different types of independent objects are returned
2. If a view is returned, use astype,
3. If the primitive type of the same value as the called object is returned, it is called typevalue
4. Static factory method, commonly used valueof or getinstance.

 

No. 39 exception only for abnormal conditions

Exceptions should only be used for abnormal conditions, and they should never be used for normal control flow.

The following is an example of an abuse exception that uses exceptions as traversal termination conditions:
// Horrible abuse of exceptions. Don't ever do this! <Br/> try {<br/> int I = 0; <br/> while (true) A [I ++]. F (); <br/>}catch (arrayindexoutofboundsexception e) {<br/>... <br/>}

There are three errors:

1. the overhead of creating, throwing, and capturing exceptions is very expensive. Because it was originally used in an abnormal situation, few JVM would optimize its performance.

2. Placing the code in try-catch will prevent JVM from implementing some specific optimizations that may have to be executed.

3. Some modern JVMs optimize the cycle without checking for redundancy.

You can use the following standard implementation methods:

For (INT I = 0; I <A. length; I ++) {<br/> A [I]. F (); <br/>}

This principle also applies to API design. A well-designed API should not force its customers to use exceptions for normal control flow. If there is a "state-related" method in the class, that is, only
For methods that can be called under specific conditions, this class should also have a separate "status test" method to check before calling this status-related method. For example, the next method and
Hasnext method.
For (iterator I = collection. iterator (); I. hasnext ();) {<br/> Foo = (FOO) I. next (); <br/>... <br/>}

Article 40th: Use of checked exceptions for recoverable conditions and runtime exceptions for program errors

Java provides three types of exceptions that can be thrown: checkedexception, run-time exception, and error ).
If the caller is expected to recover the exception during the call, the checked exception should be used to force the caller to handle the exception in catch by throwing a checked exception, or spread the exception to the outside.

Each checked exception thrown by a method declaration is a potential indication to API users: the condition associated with the exception is a possible result of calling this method.

　
There are two types of uncheckable throws: runtime exceptions and errors, which are the same in behavior. They do not need or should not be captured. All the unchecked throw structures you implement should be
A subclass of runtimeexception. It is feasible to define a non-exception, runtimeexception, or error sub-class throw,
In this sense, it is equivalent to being checked for exceptions (that is, exception subclass rather than runtimeexception subclass ).

An exception is a complete object on which any method can be defined. Because the checked exceptions often indicate recoverable conditions, you can define a method to obtain information that facilitates recovery. For details, see "Java exception classification"

No. 41 avoid unnecessary use of checked exceptions

Unlike the returned code, the checked exception forces the program to handle exceptions, greatly improving the program reliability. Excessive use of checked exceptions increases the burden that cannot be ignored. If
API usage does not prevent such exception conditions. Once an exception occurs, the program that uses the API can take useful actions. This burden is considered justified.
Try {<br/>... <br/>} catch (thecheckedexception e) {<br/> E. printstacktree (); <br/> system. exit (1); <br/>}

If API programmers cannot do better than this, the exceptions that are not checked may be more appropriate. In practice, catch has almost always the characteristics of assertion failure.

One technology that turns the checked exception into an unchecked exception is to divide this method into two methods, the first method returns a Boolean to indicate whether to throw an exception, and the other method executes the real function. If the condition is not met, an exception is thrown. As follows:
// Invocation with checked exception <br/> try {<br/> obj. action (ARGs); <br/>} catch (thecheckedexception e) {<br/> // handle exception condition <br/>}

Convert:
// Invocation with state-testing method and unchecked exception <br/> If (obj. actionpermitted (ARGs) {<br/> obj. action (ARGs); <br/>}else {<br/> // handle exception condition <br/>}

Of course, this type of conversion is not always appropriate. For example, if an object is accessed concurrently without external synchronization, or the State can be changed by the outside world, this type of conversion is not suitable.