Java- Basics – Exception Handling

reference:

  1. https://github.com/dunwu/java…

1. The Throwable class

Throwable has two major subclasses: Exception and Error; Corresponding to general exceptions and run errors (run errors are generally not caught). In Java, only instances of type Throwable can be thrown or caught. This type is an essential part of the exception-handling mechanism.

1.1 Throwable

Throwable contains a snapshot of the execution stack of a thread when the thread was created. It provides interfaces such as printStackTrace() to retrieve information such as stack trace data.

Main methods:

  • fillInStackTrace– Populate with the current call stack hierarchyThrowableObject in the stack hierarchy, added to any previous information in the stack hierarchy.
  • getMessage– Returns details about the exception that occurred. This news is inThrowableClass is initialized in the constructor of the
  • getCause– return aThrowableObject represents the cause of the exception.
  • getStackTrace– Returns an array containing the stack hierarchy. The element with a subscript of 0 represents the top of the stack, and the last element represents the bottom of the method call stack.
  • printStackTrace– printtoString()Results and stack levels toSystem.err, that is, the error output stream.
  • toString– usegetMessageThe result of the return representsThrowableObject string.

1.2 the Exception

1.3 the Error

1.4 RuntimeException

Unlike Exception, which inherits from Exception, the compiler does not check to see if RuntimeException and its subclasses are caught.

Throw & Exception Catch

  • An exception is thrown

    Throw new Exception(" throw an Exception ");

  • Exception handling

    try{
do something
}catch (Exception1 e){
do something
}catch (Exception2 e)
{
do something
}finally{
do something
}

Code sample

class BasicException extends Exception { public BasicException() { super("BasicException throw"); } public BasicException(String msg) { super(msg); }} class ChildException extends BasicException {@Override public String getMessage() {/** ** If you want to Override this class, do not Override this class The getMessage method; */ System.out.println(super.getMessage()); return "ChildException throw"; } } public class ArrayTest { public static void main(String[] args) throws Exception { // throw new BasicException(); // Exception in thread "main" BasicException: BasicException throw // at ArrayTest.main(ArrayTest.java:29) // throw new BasicException("basic"); // Exception in thread "main" BasicException: Basic // at arrayTest.main (arrayTest.java :33) // try {throw new ChildException(); } catch (childException e2) {System.out.println(" childException catch");} catch (childException e2) {System.out.println(" childException catch"); } catch (BasicException e) { System.out.println("BasicException catch"); } //ChildException catch } }
  • The effect of reflection on exception capture

Reflection of the abnormal ReflectiveOperationException class inheritance

Exception in reflection. Since reflection wraps a stack, to get the exact exception information, you should use GetTargetException to get the real exception information.

  • Multithreading and exceptions

If the child thread does not catch an exception, that thread exits.

Exception chain (deep exception thrown, reflection wrapped)

4. The tips

  • Use checking exceptions for recoverable cases and runtimeExceptions for programming errors.
  • Prefer Java standard exceptions.
  • Throws an exception corresponding to the abstraction.
  • Include information in the detail message that can catch the failure.
  • Minimize the size of the try block.
  • Minimize the scope of exceptions. For example, if the knowingly trying to capture is aArithmeticException, it should becatch ArithmeticExceptionRather thancatchwide-rangeRuntimeExceptionAnd evenException.
  • Try not tofinallyBlock throws an exception or returns a value.
  • Don’t ignore exceptions. Once caught, they should be handled rather than discarded.
  • Exception handling is inefficient, so do not use exceptions for business logic handling.
  • Each type of exception must have a separate log record, the exception classification, classification management, because sometimes only want to show the third party operation to see the logical exception, but not more detailed information.

  • How to classify exceptions:

    • Logical exceptions, which are used to describe the business cannot be handled as expected, are user-generated accidents.
    • Code errors. This type of exception is used to describe the development of code errors, such as NPE, Illarg, are programmer made bugs.
    • Proprietary exceptions, often used in business-specific scenarios to describe unexpected conditions that cannot be prehandled for a given job.