[Improve][Core][Exceptiom Management] Add Exception Management API & Unified Exception in API Module

[TyrantLucifer]

Purpose of this pull request

close #3043

Check list

• [x] Code changed are covered with tests, or it does not need tests for reason:
• [ ] If any new Jar binary package adding in your PR, please add License Notice according New License Guide
• [ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs

[Hisoka-X]

I have a different point of view, why don't we directly inherit SeaTunnelException to implement different types of Exception, but use enumeration to determine the Exception type? What is the use of Code for users? And it is impossible to manage all Exception through CommonErrorCode, and some Exceptions will use CommonErrorCode, and some will not be used.

[TyrantLucifer]

I have a different point of view, why don't we directly inherit SeaTunnelException to implement different types of Exception, but use enumeration to determine the Exception type? What is the use of Code for users? And it is impossible to manage all Exception through CommonErrorCode, and some Exceptions will use CommonErrorCode, and some will not be used.

Every connector will implement their own codes. Unified exception make error message more clearly. If we directly inherit SeaTunnelException, for all modules need create more and more exceptions. This is a good practice reference from datax.

[liugddx]

I have a different point of view, why don't we directly inherit SeaTunnelException to implement different types of Exception, but use enumeration to determine the Exception type? What is the use of Code for users? And it is impossible to manage all Exception through CommonErrorCode, and some Exceptions will use CommonErrorCode, and some will not be used.

+1. It's better to use a different implementation.

[TyrantLucifer]

I have a different point of view, why don't we directly inherit SeaTunnelException to implement different types of Exception, but use enumeration to determine the Exception type? What is the use of Code for users? And it is impossible to manage all Exception through CommonErrorCode, and some Exceptions will use CommonErrorCode, and some will not be used.

+1. It's better to use a different implementation.

So if a connector has more than 10 types exceptions, do we need define more than 10 classes to display those? It's not a good option. More More fine-grained exception I want to show what should I do?

[liugddx]

Can it be like Flink? All Connector uses FlinkRuntimeexception and definition for detailed mistakes.

[EricJoy2048]

I have a different point of view, why don't we directly inherit SeaTunnelException to implement different types of Exception, but use enumeration to determine the Exception type? What is the use of Code for users? And it is impossible to manage all Exception through CommonErrorCode, and some Exceptions will use CommonErrorCode, and some will not be used.

+1. It's better to use a different implementation.

So if a connector has more than 10 types exceptions, do we need define more than 10 classes to display those? It's not a good option. More More fine-grained exception I want to show what should I do?

That's what I'm worried about.

[TyrantLucifer]

@ashulin @Hisoka-X @EricJoy2048 @CalvinKirs @hailin0 Please review and give some suggestions. Thx

[EricJoy2048]

Hi, all. What is our conclusion? I agree with @TyrantLucifer , The exception handling of http-server <-> app-client is also the result of continuous optimization and iteration, and I think their design is very good for user experience. ErrorCode can simple help user to understand what happened in the system. On the other hand, ErrorCode can reduce randomly defined exceptions.

Especially when we need to collect error data in the future, ErrorCode can be stored in the error data together with the data. When we display the cause of the error in the web page, the ErrorCode can obtain the details of the exception, which is very helpful for the analysis of error data.