Re: [DISCUSS] Add error IDs

Hi all, I'm excited to announce that the framework for adding error classes and SQLSTATE was merged recently! (See SPARK-34920 and SPARK-34958

Re: [DISCUSS] Add error IDs

I think severity makes sense for logs, but not sure about errors. +1 to the proposal to improve the error message further. On Fri, Apr 16, 2021 at 6:01 PM Yuming Wang wrote: > +1 for this proposal. > > On Fri, Apr 16, 2021 at 5:15 AM Karen wrote: > >> We could leave space in the numbering syst

Re: [DISCUSS] Add error IDs

+1 for this proposal. On Fri, Apr 16, 2021 at 5:15 AM Karen wrote: > We could leave space in the numbering system, but a more flexible method > may be to have the severity as a field associated with the error class - > the same way we would associate error ID with SQLSTATE, or with whether an >

Re: [DISCUSS] Add error IDs

We could leave space in the numbering system, but a more flexible method may be to have the severity as a field associated with the error class - the same way we would associate error ID with SQLSTATE, or with whether an error is user-facing or internal. As you noted, I don't believe there is a sta

Re: [DISCUSS] Add error IDs

Machine readable logs are always good, especially if you can read the entire logs into an SQL query. It might be good to use some specific differentiation between hint/warn/fatal error in the numbering so that any automated analysis of the logs can identify the class of an error even if its an err

[DISCUSS] Add error IDs

Hi all, We would like to kick off a discussion on adding error IDs to Spark. Proposal: Add error IDs to provide a language-agnostic, locale-agnostic, specific, and succinct answer for which class the problem falls under. When partnered with a text-based error class (eg. 12345 TABLE_OR_VIEW_NOT_F