You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@seatunnel.apache.org by TaoZex <26...@qq.com.INVALID> on 2022/10/14 03:31:50 UTC

RE: [Discuss] Unified exception management in whole project

When a program reports an error, as we do, the user's first reaction is to look at the printed error message, so it is essential to have enough exception message. If we want to explain it further and more clearly, we'd better add ErrorDataCollect.


Best wishes!
TaoZex
------------------&nbsp;原始邮件&nbsp;------------------
发件人:                                                                                                                        "dev"                                                                                    <gaojun2048@apache.org&gt;;
发送时间:&nbsp;2022年10月14日(星期五) 中午11:24
收件人:&nbsp;"dev"<dev@seatunnel.apache.org&gt;;

主题:&nbsp;Re: [Discuss] Unified exception management in whole project



Don't wrong, ErrorDataCollect need define the error data info schema, the
schema need have sufficient fields to clearly describe the context
information.

CalvinKirs <acm_master@163.com&gt; 于2022年10月14日周五 11:13写道:

&gt; If there is no clear context, then it just drives people crazy, the point
&gt; is how you relate these error data files, they may not be the same error
&gt; type. Also, how do you go about unifying the style with some code-wise
&gt; statute.
&gt;
&gt;
&gt; Best wishes!
&gt; Calvin Kirs
&gt;
&gt;
&gt; On 10/14/2022 11:08,JUN GAO<gaojun2048@apache.org&gt; wrote:
&gt; Use Exception to print error data is not a good idea. Because may have a
&gt; lot of error data.
&gt;
&gt; I suggestion we add an ErrorDataCollect to collect the error data,
&gt; ErrorDataCollect can write the error data to file or something else.
&gt;
&gt; CalvinKirs <acm_master@163.com&gt; 于2022年10月14日周五 10:38写道:
&gt;
&gt; Just as a suggestion, regarding some data exceptions, we'd better be able
&gt; to force the corresponding data parameters to be output, which is more
&gt; beneficial for users to troubleshoot the problem. For other exceptions as
&gt; well, it is very important to have the necessary context for the
&gt; concatenation.
&gt;
&gt;
&gt; Best wishes!
&gt; Calvin Kirs
&gt;
&gt;
&gt; On 10/14/2022 00:38,Lucifer Tyrant<tyrantlucifer@apache.org&gt; wrote:
&gt; Hi community,
&gt;
&gt; According to the latest discussion, I've revised the design and
&gt; submitted a new example, I'd appreciate your comments.
&gt;
&gt; Issue: https://github.com/apache/incubator-seatunnel/issues/3043
&gt; Example pull request:
&gt; https://github.com/apache/incubator-seatunnel/pull/3045
&gt;
&gt; Best Regards,
&gt; Chao Tian
&gt;
&gt;
&gt; Zongwen Li <zongwen@apache.org&gt; 于2022年10月11日周二 10:12写道:
&gt;
&gt; +1, Generic exceptions are necessary.
&gt;
&gt; CalvinKirs <acm_master@163.com&gt; 于2022年10月11日周二 09:53写道:
&gt;
&gt; I'm not just talking about connector, we also have other modules, such as
&gt; engine, connector exceptions you can define a, but in general, the
&gt; exception definition has its business meaning, just the exceptions are
&gt; broad to facilitate the problem of troubleshooting positioning.
&gt;
&gt; In addition, this belongs to the basic specification, we do not need to
&gt; reflect in the documentation, we are more concerned about SeaTunnel itself
&gt; things.
&gt;
&gt;
&gt; Best wishes!
&gt; Calvin Kirs
&gt;
&gt;
&gt; On 10/11/2022 09:48,Lucifer Tyrant<tyrantlucifer@apache.org&gt; wrote:
&gt; Hi CalvinKirs,
&gt;
&gt; So far, we have developed dozens of connectors, for these connectors are
&gt; actually similar to the limited exceptions, to define different exceptions
&gt; performance strength is very limited, for example, we may have a variety of
&gt; exceptions in the clickhouse connector, such as cluster connection timeout,
&gt; incorrect password, data table schema query failure, etc., this kind of
&gt; fine strength of the exception tips. Do we all need to redefine a new
&gt; exception type? I think this is not advisable, if the connector has up to
&gt; 10 or more types of error hints, we will define 10 or more classes for a
&gt; better user experience, which will lead to redundant and unclear code,
&gt; using a unified exception and error code representation will have a clearer
&gt; and more powerful presentation.
&gt;
&gt; Best Regards,
&gt; Chao Tian
&gt;
&gt; CalvinKirs <acm_master@163.com&gt; 于 2022年10月10日周一 下午7:08写道:
&gt;
&gt; We should use custom exceptions that have business implications. The
&gt; reliance on uniform exceptions is usually to avoid uncaught exceptions, and
&gt; we can go ahead and create some public exceptions, such as the public
&gt; exception for connector.
&gt;
&gt;
&gt; Best wishes!
&gt; Calvin Kirs
&gt;
&gt;
&gt; On 10/10/2022 18:49,JUN GAO<gaojun2048@apache.org&gt; wrote:
&gt; It's a good idea.
&gt;
&gt; Lucifer Tyrant <tyrantlucifer@apache.org&gt; 于2022年10月10日周一 14:22写道:
&gt;
&gt; Hi all,
&gt;
&gt; So far, the exceptions thrown in the code have not been managed uniformly,
&gt; the connector and other modules still use RuntimeException, unified
&gt; exception management can make the code more clear and easy to read, and
&gt; quickly prompt the user where the exception occurred.
&gt;
&gt; My idea is a consistent global exception with error codes and error hints
&gt; when throwing exceptions.
&gt;
&gt; My idea is that the global exceptions are consistent, with error codes and
&gt; error hints when throwing exceptions, the advantage of doing so is that it
&gt; can unify the error message hints, and the unified format helps provide a
&gt; better experience for users, when users encounter problems in the process
&gt; of use, users can directly locate the problem through the error code and
&gt; hint information quickly or submit the error code to the community, this
&gt; idea is also borrowed from DataX. For more detailed design, please refer to
&gt; the issue:
&gt;
&gt; https://github.com/apache/incubator-seatunnel/issues/3043
&gt;
&gt; If you have better suggestions and solutions, welcome to discuss together☺,
&gt; let's make SeaTunnel better and more powerful together.💪
&gt;
&gt; Best Regards,
&gt; Chao Tian
&gt;
&gt;
&gt;
&gt; --
&gt;
&gt; Best Regards
&gt;
&gt; ------------
&gt;
&gt; EricJoy2048
&gt; gaojun2048@gmail.com
&gt;
&gt;
&gt;
&gt; --
&gt; Best Regards,
&gt;
&gt; Zongwen Li
&gt;
&gt;
&gt;
&gt; --
&gt;
&gt; Best Regards
&gt;
&gt; ------------
&gt;
&gt; EricJoy2048
&gt; gaojun2048@gmail.com
&gt;


-- 

Best Regards

------------

EricJoy2048
gaojun2048@gmail.com