Hi CalvinKris, So as your means, we should define different exception types for every base module, such as [engine] [connectors] [apis] [translation] etc.
Every module has its own base Exception, for example, connectors module using SeaTunnelConnectorException, engine module using SeaTunnelEngineException and so on. More detail of error messages using error codes to show. Do I understand correctly? Best Regards, Chao Tian CalvinKirs <[email protected]> 于2022年10月11日周二 09:53写道： > I'm not just talking about connector, we also have other modules, such as > engine, connector exceptions you can define a, but in general, the > exception definition has its business meaning, just the exceptions are > broad to facilitate the problem of troubleshooting positioning. > > In addition, this belongs to the basic specification, we do not need to > reflect in the documentation, we are more concerned about SeaTunnel itself > things. > > > Best wishes！ > Calvin Kirs > > > On 10/11/2022 09:48，Lucifer Tyrant<[email protected]> wrote： > Hi CalvinKirs, > > So far, we have developed dozens of connectors, for these connectors are > actually similar to the limited exceptions, to define different exceptions > performance strength is very limited, for example, we may have a variety of > exceptions in the clickhouse connector, such as cluster connection timeout, > incorrect password, data table schema query failure, etc., this kind of > fine strength of the exception tips. Do we all need to redefine a new > exception type? I think this is not advisable, if the connector has up to > 10 or more types of error hints, we will define 10 or more classes for a > better user experience, which will lead to redundant and unclear code, > using a unified exception and error code representation will have a clearer > and more powerful presentation. > > Best Regards, > Chao Tian > > CalvinKirs <[email protected]> 于 2022年10月10日周一 下午7:08写道： > > We should use custom exceptions that have business implications. The > reliance on uniform exceptions is usually to avoid uncaught exceptions, and > we can go ahead and create some public exceptions, such as the public > exception for connector. > > > Best wishes！ > Calvin Kirs > > > On 10/10/2022 18:49，JUN GAO<[email protected]> wrote： > It's a good idea. > > Lucifer Tyrant <[email protected]> 于2022年10月10日周一 14:22写道： > > Hi all, > > So far, the exceptions thrown in the code have not been managed uniformly, > the connector and other modules still use RuntimeException, unified > exception management can make the code more clear and easy to read, and > quickly prompt the user where the exception occurred. > > My idea is a consistent global exception with error codes and error hints > when throwing exceptions. > > My idea is that the global exceptions are consistent, with error codes and > error hints when throwing exceptions, the advantage of doing so is that it > can unify the error message hints, and the unified format helps provide a > better experience for users, when users encounter problems in the process > of use, users can directly locate the problem through the error code and > hint information quickly or submit the error code to the community, this > idea is also borrowed from DataX. For more detailed design, please refer to > the issue: > > https://github.com/apache/incubator-seatunnel/issues/3043 > > If you have better suggestions and solutions, welcome to discuss together☺, > let's make SeaTunnel better and more powerful together.💪 > > Best Regards, > Chao Tian > > > > -- > > Best Regards > > ------------ > > EricJoy2048 > [email protected] > >
