When I was looking at the Hadoop source code today, I thought about the system I was working on recently, and found that many exception handling methods were wrong. They still followed the traditional exception handling method (that is, using return values to identify programs anomalies occur). The declaration of many methods in Hadoop throws exceptions, but the declaration of many methods in my system does not throw exceptions. It only detects the abnormal situation and outputs an error message, but does not throw an exception.
The readFields() method of the Block class under the org.apache.hadoop.hdfs.protocol package:
public void readFields(DataInput in) throws IOException { this.blockId = in.readLong(); this.numBytes = in.readLong(); this.generationStamp = in.readLong(); if (numBytes < 0) { throw new IOException("Unexpected block size: " + numBytes);//抛出异常,要是的话就不会抛出,而只是System.out.println错误提示, }
1. If there is a throws exception in the method declaration name, then the method body does not need to throw an exception. Because you can include an exception description in the method declaration, but not actually throw it! The advantage of doing this is that you have a place for the exception first, and you can throw this exception later without modifying the existing code. This ability is important when defining abstract base classes and interfaces so that derived classes or interface implementing classes can throw these pre-declared exceptions.
2. Why do some method declarations have no throws, but exceptions are thrown in the method body? Exceptions inherited from RuntimeException can be thrown without exception description throws! For runtime exceptions (also called unchecked exceptions), the compiler does not require an exception description. Exceptions of type RuntimeException (and its subclasses) can only be ignored in the code. The handling of other types of exceptions is enforced by the compiler. The reason is that RuntimeException represents a programming error.
3. Runtime exceptions will be automatically thrown by the Java virtual machine!
Exception handling basics
1.1 System.out.println is expensive. Calling System.out.println will reduce system throughput.
1.2 Do not use the abnormal printStackTrace() method in a production environment. printStackTrace will print the call stack to the console by default. It is unrealistic to access the console in a production environment.
Basic principles of exception handling
2.1 If you can't handle an exception, don't catch it.
2.2 If you want to catch it, you should catch it close to the source of the exception.
2.3 Don’t swallow exceptions you catch.
*(It is a caught exception, but does nothing)
2.4 Unless you want to rethrow the exception, log it.
2.5 When an exception is repackaged and then rethrown, do not print a statck trace.
2.6 Use a custom exception class instead of throwing java.lang.Exception every time you need to throw an exception. The caller of the method knows which exceptions need to be handled via throws – so it is self-describing.
2.7 If you write business logic, the system should throw an unchecked exception (unchecked exception) for errors that cannot be repaired by end users; if you write a third-party package for other developers to use, for Unrepairable errors require a checked exception.
2.8 Never fail to declare exceptions that need to be checked because writing throws statements will make you uncomfortable to use.
2.9 Application-level errors or unrepairable system exceptions are thrown using unchecked exceptions.
* (Note that it is an error, which means it cannot be repaired, such as a configuration file error)
2.10 Organize your methods according to the granularity of exceptions
Related recommendations:
Basic knowledge of java exceptions and error handling
Regain the basics of java (16): Summary of exceptions
The above is the detailed content of Java exception handling foundation and basic principles. For more information, please follow other related articles on the PHP Chinese website!