When throwing, is it necessary to new the exception object?

When to throw? It’s usually in the catch.

When throwing, is it necessary to new the exception object?

In general, there is no need to throw the original exception in the catch.

That is, any exception caught will be thrown.

Rather than new an exception again — unless you really want to convert the catch to something else, such as a new custom state and custom description.

If the exception object is new, the disadvantage is that 1. The object is new once more. 2

catch(BizException e){ log.error("xxx"); throw new BizException(e); // Throw new BizException(e)}Copy the code

Why are the custom fields of the original exception in the catch missing?

When a new exception object is created, only the description field of the JDK exception class is copied over, and other custom fields (including the custom status and custom description) are lost.

When a new exception object is created, only the description field of the JDK exception class is copied. Also, if the custom exception class overrides the toString() method, the value of the exception description information is the value returned by the toString() method of the original exception class.

Public class BizException extends RuntimeException {protected String _errorCode = "9900"; public Class BizException extends RuntimeException {protected String _errorCode = "9900"; / / state. Protected String _moduleCode = ""; protected String _moduleName = ""; protected String _subsystem = ""; protected Throwable _exception; Public BizException(Throwable cause) {super(cause); this.setModule(); } public String toString() { String desc = this.getFullMessage(); if (this._exception ! = null) {desc = desc + "+ this._exception; } return desc; } public String getFullMessage() { String info; if (this._moduleCode ! = null && ! This._modulecode.isempty ()) {info = "module {" + this._subsystem + ":" + this._modulecode + "}, error code {" + this._errorCode + "}, error description {" + this.getMessage() + "}"; {} else {info = "modules" + enclosing _subsystem + "}, error code {} ". + this _errorCode + ", error description {" + this. GetMessage () + "} "; } return info; }Copy the code

Cast casting

A subclass is cast to a parent class, no problem.

Casting a parent class to a subclass can be problematic. The solution? You must verify that an instance object of a parent class is an instance object of a subclass, that is, by the instanceof keyword. If yes, the cast can be performed. If not, the cast is problematic.

Summary: 1> instanceof tests whether the modifier to its left is an instanceof the class to its right. 2> When writing a Java program, a reference variable can only call a method of its compile-time type, not a method of its run-time type, even if the object it actually refers to actually contains that method. If you want the reference variable to call a method of its runtime type, you must cast it to the runtime type. However, in the process of casting, it is possible to cause a ClassCastException (ClassCastException), the method to avoid it is also very simple, use the instanceof keyword to determine whether the object is of this class, if true, and then cast. ———————————————— Copyright notice: This article is originally published BY CSDN blogger "Yfl_ iOS". It is subject to CC 4.0 BY-SA copyright agreement. Please attach the link of the original source and this statement. The original link: https://blog.csdn.net/qq_18505715/article/details/72631576Copy the code

The same rules apply to casts of exception classes.

What does a cast do?

This is typically done to access data and methods of the cast type (that is, a subclass). Without conversion, the parent class cannot access the data and methods of the child class.

conclusion

Where does the exception come from?

1. When external channel exceptions cross the company, they are encapsulated as result objects (including status and description fields) rather than directly thrown exceptions.

2. The company channel exception is cross-department. It is better not to throw it directly once, but encapsulate it as a result object (including status and description information fields).

3. Scan code exception 1) transaction item 2) pre-item 3) Gateway project different items within the department, can directly throw exceptions.

When throwing exceptions across projects, 1. It is best not to use the new exception object, because the value of the custom field of the custom exception will be lost. 2. Unless you really want to convert to another custom exception class, you should also bring the new custom state and custom fields.

That is, always bring the status and description of the exception, because the result needs to be differentiated according to the status. Different processing or different information is displayed according to the status (you may need to convert the original description to a customized service description).