Hi, all. What is our conclusion? I agree with @TyrantLucifer <https://github.com/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. JUN GAO <[email protected]> 于2022年10月14日周五 14:25写道： > If we throw an Exception when the data error, it means the job need failed > and stop. Sometimes user don't want the job failed, the best way is collect > the error data and skip write it to sink. > > Lucifer Tyrant <[email protected]> 于2022年10月14日周五 11:36写道： > >> The current solution does not insist on using a unified exception >> class, developers can add new exceptions with special business >> meaning, it is only recommended to add error code hints when throwing >> exceptions, this will help reduce user learning costs, the dimension >> of whether a tool works well is whether the user can quickly get >> started and quickly solve the problems in use. >> >> Best Regards, >> Chao Tian >> >> JUN GAO <[email protected]> 于2022年10月14日周五 11:25写道： >> > >> > Don't wrong, ErrorDataCollect need define the error data info schema, >> the >> > schema need have sufficient fields to clearly describe the context >> > information. >> > >> > CalvinKirs <[email protected]> 于2022年10月14日周五 11:13写道： >> > >> > > If there is no clear context, then it just drives people crazy, the >> point >> > > is how you relate these error data files, they may not be the same >> error >> > > type. Also, how do you go about unifying the style with some code-wise >> > > statute. >> > > >> > > >> > > Best wishes！ >> > > Calvin Kirs >> > > >> > > >> > > On 10/14/2022 11:08，JUN GAO<[email protected]> wrote： >> > > Use Exception to print error data is not a good idea. Because may >> have a >> > > lot of error data. >> > > >> > > I suggestion we add an ErrorDataCollect to collect the error data, >> > > ErrorDataCollect can write the error data to file or something else. >> > > >> > > CalvinKirs <[email protected]> 于2022年10月14日周五 10:38写道： >> > > >> > > Just as a suggestion, regarding some data exceptions, we'd better be >> able >> > > to force the corresponding data parameters to be output, which is more >> > > beneficial for users to troubleshoot the problem. For other >> exceptions as >> > > well, it is very important to have the necessary context for the >> > > concatenation. >> > > >> > > >> > > Best wishes！ >> > > Calvin Kirs >> > > >> > > >> > > On 10/14/2022 00:38，Lucifer Tyrant<[email protected]> wrote： >> > > Hi community, >> > > >> > > According to the latest discussion, I've revised the design and >> > > submitted a new example, I'd appreciate your comments. >> > > >> > > Issue: https://github.com/apache/incubator-seatunnel/issues/3043 >> > > Example pull request: >> > > https://github.com/apache/incubator-seatunnel/pull/3045 >> > > >> > > Best Regards, >> > > Chao Tian >> > > >> > > >> > > Zongwen Li <[email protected]> 于2022年10月11日周二 10:12写道： >> > > >> > > +1, Generic exceptions are necessary. >> > > >> > > 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] >> > > >> > > >> > > >> > > -- >> > > Best Regards, >> > > >> > > Zongwen Li >> > > >> > > >> > > >> > > -- >> > > >> > > Best Regards >> > > >> > > ------------ >> > > >> > > EricJoy2048 >> > > [email protected] >> > > >> > >> > >> > -- >> > >> > Best Regards >> > >> > ------------ >> > >> > EricJoy2048 >> > [email protected] >> > > > -- > > Best Regards > > ------------ > > EricJoy2048 > [email protected] > > -- Best Regards ------------ EricJoy2048 [email protected]
