You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Michael Cherkasov <mi...@gmail.com> on 2020/12/31 23:07:05 UTC
Error Codes
Hi folks,
I was thinking how we can simplify Ignite clusters troubleshooting and the
best of course if the cluster can do self-healing, like transaction
cancellation if tx blocks exchange or note restart on OOM error. However,
sometimes those mechanisms don't work well or user interaction is required.
Not all errors are obvious for users and it's not clear what actions
required to restore the cluster.
If you google exceptions or error messages and the results can be
ambiguous and not certain because different errors can have similar
exceptions and you need to analyze stack trace to distinguish them. So
googling isn't a straight and easy process in this case.
Almost all major DBs have error codes[1][2][3]
Let's do the same for Ignite, error codes easy to google, so user/dev list
will be significantly more useful. We can have documentation with an error
code registry and solutions for the errors.
To implement this we need to do the following:
1. all error messages/exceptions must have a unique error code(so, all new
PR must NOT be accepted if any exceptions/errors don't have error codes.)
2. to avoid error code duplication, all error codes will be stored as files
under some folder.
3. those files can be a source of documentation for this error code.
All this files can be empty, but futher, if exception will apper on user
list and someone will find solution, first, other people can easialy google
it by error code, and second, we can build documentation for this error
code base on user-list thread/stackoverflow/other source.
Any thoughts?
[1] Mysql
https://dev.mysql.com/doc/refman/8.0/en/error-message-elements.html
[2] OracleDB https://docs.oracle.com/pls/db92/db92.error_search
[3] PostgreSQL https://www.postgresql.org/docs/10/errcodes-appendix.html
Thanks,
Mike.
Re: Error Codes
Posted by Denis Magda <dm...@apache.org>.
Val, excellent, thanks.
Here is the ticket: https://issues.apache.org/jira/browse/IGNITE-3690
Mike, feel free to put useful pointers there.
-
Denis
On Tue, Jan 5, 2021 at 2:31 PM Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:
> Mike, Denis,
>
> Having error codes certainly makes sense. Please send the ticket link, and
> we'll go from there.
>
> -Val
>
> On Mon, Jan 4, 2021 at 7:50 PM Denis Magda <dm...@apache.org> wrote:
>
> > Do back this idea up of having a glossary of common errors. There is even
> > a ticket for that I created a couple of years ago. Can search for it
> later.
> >
> > Val, how about the 3.0 suggestion? Let’s introduce error codes.
> >
> > On Monday, January 4, 2021, Michael Cherkasov <
> michael.cherkasov@gmail.com>
> > wrote:
> >
> >> Hi Ilya,
> >>
> >> It's about logs only, I don't think we need this at the API level. Error
> >> codes will make the solutions more searchable.
> >> Plus we can build troubleshooting guides based on it, it will help us
> >> gather information from user list and StackOverflow.
> >>
> >> Even a solution for trivial cases will be helpful, once I was requested
> >> to join the call late evening because ignite failed to copy WAL file and
> >> there just was no space on the disk.
> >> While the error was obvious for me, it's not obvious for all users.
> >>
> >> Let's start from something simple, just assign error codes to
> >> absolutely all exceptions first. So next year or two user list will
> full of
> >> error codes and solutions for them.
> >>
> >> Might be it's a change for Ignite 3.0? @Val, I think you can help with
> >> this question.
> >>
> >> Any thoughts/comments?
> >>
> >> Thanks,
> >> Mike.
> >>
> >> сб, 2 янв. 2021 г. в 12:18, Ilya Kasnacheev <ilya.kasnacheev@gmail.com
> >:
> >>
> >>> Hello!
> >>>
> >>> I don't think there's a direct link between an exception thrown in
> >>> depths of Ignite code, and specific error which may be reported to
> user.
> >>>
> >>> A notorious example is CorruptedTreeException which is known to be
> >>> thrown due to incorrect field type in binary object or bad SQL cast.
> So we
> >>> could document it "If you get IGN13 error this means your persistence
> is
> >>> corrupted beyond repair. This, or you have a typo in your SQL." - of
> course
> >>> it will not help anyone.
> >>>
> >>> This means we can't get to the desired result by application of 1.
> >>>
> >>> There's got to be a different plan. First of all, we need to decide
> >>> what's our target. Is it log, or is it API?
> >>>
> >>> Regards,
> >>> --
> >>> Ilya Kasnacheev
> >>>
> >>>
> >>> пт, 1 янв. 2021 г. в 02:07, Michael Cherkasov <
> >>> michael.cherkasov@gmail.com>:
> >>>
> >>>> Hi folks,
> >>>>
> >>>> I was thinking how we can simplify Ignite clusters troubleshooting and
> >>>> the best of course if the cluster can do self-healing, like
> transaction
> >>>> cancellation if tx blocks exchange or note restart on OOM error.
> However,
> >>>> sometimes those mechanisms don't work well or user interaction is
> required.
> >>>> Not all errors are obvious for users and it's not clear what actions
> >>>> required to restore the cluster.
> >>>> If you google exceptions or error messages and the results can be
> >>>> ambiguous and not certain because different errors can have similar
> >>>> exceptions and you need to analyze stack trace to distinguish them. So
> >>>> googling isn't a straight and easy process in this case.
> >>>> Almost all major DBs have error codes[1][2][3]
> >>>> Let's do the same for Ignite, error codes easy to google, so user/dev
> >>>> list will be significantly more useful. We can have documentation
> with an
> >>>> error code registry and solutions for the errors.
> >>>>
> >>>> To implement this we need to do the following:
> >>>> 1. all error messages/exceptions must have a unique error code(so, all
> >>>> new PR must NOT be accepted if any exceptions/errors don't have error
> >>>> codes.)
> >>>> 2. to avoid error code duplication, all error codes will be stored as
> >>>> files under some folder.
> >>>> 3. those files can be a source of documentation for this error code.
> >>>>
> >>>> All this files can be empty, but futher, if exception will apper on
> >>>> user list and someone will find solution, first, other people can
> easialy
> >>>> google it by error code, and second, we can build documentation for
> this
> >>>> error code base on user-list thread/stackoverflow/other source.
> >>>>
> >>>> Any thoughts?
> >>>>
> >>>> [1] Mysql
> >>>> https://dev.mysql.com/doc/refman/8.0/en/error-message-elements.html
> >>>> [2] OracleDB https://docs.oracle.com/pls/db92/db92.error_search
> >>>> [3] PostgreSQL
> >>>> https://www.postgresql.org/docs/10/errcodes-appendix.html
> >>>>
> >>>> Thanks,
> >>>> Mike.
> >>>>
> >>>
> >
> > --
> > -
> > Denis
> >
> >
>
Re: Error Codes
Posted by Valentin Kulichenko <va...@gmail.com>.
Mike, Denis,
Having error codes certainly makes sense. Please send the ticket link, and
we'll go from there.
-Val
On Mon, Jan 4, 2021 at 7:50 PM Denis Magda <dm...@apache.org> wrote:
> Do back this idea up of having a glossary of common errors. There is even
> a ticket for that I created a couple of years ago. Can search for it later.
>
> Val, how about the 3.0 suggestion? Let’s introduce error codes.
>
> On Monday, January 4, 2021, Michael Cherkasov <mi...@gmail.com>
> wrote:
>
>> Hi Ilya,
>>
>> It's about logs only, I don't think we need this at the API level. Error
>> codes will make the solutions more searchable.
>> Plus we can build troubleshooting guides based on it, it will help us
>> gather information from user list and StackOverflow.
>>
>> Even a solution for trivial cases will be helpful, once I was requested
>> to join the call late evening because ignite failed to copy WAL file and
>> there just was no space on the disk.
>> While the error was obvious for me, it's not obvious for all users.
>>
>> Let's start from something simple, just assign error codes to
>> absolutely all exceptions first. So next year or two user list will full of
>> error codes and solutions for them.
>>
>> Might be it's a change for Ignite 3.0? @Val, I think you can help with
>> this question.
>>
>> Any thoughts/comments?
>>
>> Thanks,
>> Mike.
>>
>> сб, 2 янв. 2021 г. в 12:18, Ilya Kasnacheev <il...@gmail.com>:
>>
>>> Hello!
>>>
>>> I don't think there's a direct link between an exception thrown in
>>> depths of Ignite code, and specific error which may be reported to user.
>>>
>>> A notorious example is CorruptedTreeException which is known to be
>>> thrown due to incorrect field type in binary object or bad SQL cast. So we
>>> could document it "If you get IGN13 error this means your persistence is
>>> corrupted beyond repair. This, or you have a typo in your SQL." - of course
>>> it will not help anyone.
>>>
>>> This means we can't get to the desired result by application of 1.
>>>
>>> There's got to be a different plan. First of all, we need to decide
>>> what's our target. Is it log, or is it API?
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> пт, 1 янв. 2021 г. в 02:07, Michael Cherkasov <
>>> michael.cherkasov@gmail.com>:
>>>
>>>> Hi folks,
>>>>
>>>> I was thinking how we can simplify Ignite clusters troubleshooting and
>>>> the best of course if the cluster can do self-healing, like transaction
>>>> cancellation if tx blocks exchange or note restart on OOM error. However,
>>>> sometimes those mechanisms don't work well or user interaction is required.
>>>> Not all errors are obvious for users and it's not clear what actions
>>>> required to restore the cluster.
>>>> If you google exceptions or error messages and the results can be
>>>> ambiguous and not certain because different errors can have similar
>>>> exceptions and you need to analyze stack trace to distinguish them. So
>>>> googling isn't a straight and easy process in this case.
>>>> Almost all major DBs have error codes[1][2][3]
>>>> Let's do the same for Ignite, error codes easy to google, so user/dev
>>>> list will be significantly more useful. We can have documentation with an
>>>> error code registry and solutions for the errors.
>>>>
>>>> To implement this we need to do the following:
>>>> 1. all error messages/exceptions must have a unique error code(so, all
>>>> new PR must NOT be accepted if any exceptions/errors don't have error
>>>> codes.)
>>>> 2. to avoid error code duplication, all error codes will be stored as
>>>> files under some folder.
>>>> 3. those files can be a source of documentation for this error code.
>>>>
>>>> All this files can be empty, but futher, if exception will apper on
>>>> user list and someone will find solution, first, other people can easialy
>>>> google it by error code, and second, we can build documentation for this
>>>> error code base on user-list thread/stackoverflow/other source.
>>>>
>>>> Any thoughts?
>>>>
>>>> [1] Mysql
>>>> https://dev.mysql.com/doc/refman/8.0/en/error-message-elements.html
>>>> [2] OracleDB https://docs.oracle.com/pls/db92/db92.error_search
>>>> [3] PostgreSQL
>>>> https://www.postgresql.org/docs/10/errcodes-appendix.html
>>>>
>>>> Thanks,
>>>> Mike.
>>>>
>>>
>
> --
> -
> Denis
>
>
Re: Error Codes
Posted by Denis Magda <dm...@apache.org>.
Do back this idea up of having a glossary of common errors. There is even a
ticket for that I created a couple of years ago. Can search for it later.
Val, how about the 3.0 suggestion? Let’s introduce error codes.
On Monday, January 4, 2021, Michael Cherkasov <mi...@gmail.com>
wrote:
> Hi Ilya,
>
> It's about logs only, I don't think we need this at the API level. Error
> codes will make the solutions more searchable.
> Plus we can build troubleshooting guides based on it, it will help us
> gather information from user list and StackOverflow.
>
> Even a solution for trivial cases will be helpful, once I was requested to
> join the call late evening because ignite failed to copy WAL file and there
> just was no space on the disk.
> While the error was obvious for me, it's not obvious for all users.
>
> Let's start from something simple, just assign error codes to
> absolutely all exceptions first. So next year or two user list will full of
> error codes and solutions for them.
>
> Might be it's a change for Ignite 3.0? @Val, I think you can help with
> this question.
>
> Any thoughts/comments?
>
> Thanks,
> Mike.
>
> сб, 2 янв. 2021 г. в 12:18, Ilya Kasnacheev <il...@gmail.com>:
>
>> Hello!
>>
>> I don't think there's a direct link between an exception thrown in depths
>> of Ignite code, and specific error which may be reported to user.
>>
>> A notorious example is CorruptedTreeException which is known to be thrown
>> due to incorrect field type in binary object or bad SQL cast. So we could
>> document it "If you get IGN13 error this means your persistence is
>> corrupted beyond repair. This, or you have a typo in your SQL." - of course
>> it will not help anyone.
>>
>> This means we can't get to the desired result by application of 1.
>>
>> There's got to be a different plan. First of all, we need to decide
>> what's our target. Is it log, or is it API?
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> пт, 1 янв. 2021 г. в 02:07, Michael Cherkasov <
>> michael.cherkasov@gmail.com>:
>>
>>> Hi folks,
>>>
>>> I was thinking how we can simplify Ignite clusters troubleshooting and
>>> the best of course if the cluster can do self-healing, like transaction
>>> cancellation if tx blocks exchange or note restart on OOM error. However,
>>> sometimes those mechanisms don't work well or user interaction is required.
>>> Not all errors are obvious for users and it's not clear what actions
>>> required to restore the cluster.
>>> If you google exceptions or error messages and the results can be
>>> ambiguous and not certain because different errors can have similar
>>> exceptions and you need to analyze stack trace to distinguish them. So
>>> googling isn't a straight and easy process in this case.
>>> Almost all major DBs have error codes[1][2][3]
>>> Let's do the same for Ignite, error codes easy to google, so user/dev
>>> list will be significantly more useful. We can have documentation with an
>>> error code registry and solutions for the errors.
>>>
>>> To implement this we need to do the following:
>>> 1. all error messages/exceptions must have a unique error code(so, all
>>> new PR must NOT be accepted if any exceptions/errors don't have error
>>> codes.)
>>> 2. to avoid error code duplication, all error codes will be stored as
>>> files under some folder.
>>> 3. those files can be a source of documentation for this error code.
>>>
>>> All this files can be empty, but futher, if exception will apper on user
>>> list and someone will find solution, first, other people can easialy google
>>> it by error code, and second, we can build documentation for this error
>>> code base on user-list thread/stackoverflow/other source.
>>>
>>> Any thoughts?
>>>
>>> [1] Mysql https://dev.mysql.com/doc/refman/8.0/en/error-
>>> message-elements.html
>>> [2] OracleDB https://docs.oracle.com/pls/db92/db92.error_search
>>> [3] PostgreSQL https://www.postgresql.org/docs/10/errcodes-appendix.html
>>>
>>> Thanks,
>>> Mike.
>>>
>>
--
-
Denis
Re: Error Codes
Posted by Michael Cherkasov <mi...@gmail.com>.
Hi Ilya,
It's about logs only, I don't think we need this at the API level. Error
codes will make the solutions more searchable.
Plus we can build troubleshooting guides based on it, it will help us
gather information from user list and StackOverflow.
Even a solution for trivial cases will be helpful, once I was requested to
join the call late evening because ignite failed to copy WAL file and there
just was no space on the disk.
While the error was obvious for me, it's not obvious for all users.
Let's start from something simple, just assign error codes to
absolutely all exceptions first. So next year or two user list will full of
error codes and solutions for them.
Might be it's a change for Ignite 3.0? @Val, I think you can help with this
question.
Any thoughts/comments?
Thanks,
Mike.
сб, 2 янв. 2021 г. в 12:18, Ilya Kasnacheev <il...@gmail.com>:
> Hello!
>
> I don't think there's a direct link between an exception thrown in depths
> of Ignite code, and specific error which may be reported to user.
>
> A notorious example is CorruptedTreeException which is known to be thrown
> due to incorrect field type in binary object or bad SQL cast. So we could
> document it "If you get IGN13 error this means your persistence is
> corrupted beyond repair. This, or you have a typo in your SQL." - of course
> it will not help anyone.
>
> This means we can't get to the desired result by application of 1.
>
> There's got to be a different plan. First of all, we need to decide what's
> our target. Is it log, or is it API?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 1 янв. 2021 г. в 02:07, Michael Cherkasov <michael.cherkasov@gmail.com
> >:
>
>> Hi folks,
>>
>> I was thinking how we can simplify Ignite clusters troubleshooting and
>> the best of course if the cluster can do self-healing, like transaction
>> cancellation if tx blocks exchange or note restart on OOM error. However,
>> sometimes those mechanisms don't work well or user interaction is required.
>> Not all errors are obvious for users and it's not clear what actions
>> required to restore the cluster.
>> If you google exceptions or error messages and the results can be
>> ambiguous and not certain because different errors can have similar
>> exceptions and you need to analyze stack trace to distinguish them. So
>> googling isn't a straight and easy process in this case.
>> Almost all major DBs have error codes[1][2][3]
>> Let's do the same for Ignite, error codes easy to google, so user/dev
>> list will be significantly more useful. We can have documentation with an
>> error code registry and solutions for the errors.
>>
>> To implement this we need to do the following:
>> 1. all error messages/exceptions must have a unique error code(so, all
>> new PR must NOT be accepted if any exceptions/errors don't have error
>> codes.)
>> 2. to avoid error code duplication, all error codes will be stored as
>> files under some folder.
>> 3. those files can be a source of documentation for this error code.
>>
>> All this files can be empty, but futher, if exception will apper on user
>> list and someone will find solution, first, other people can easialy google
>> it by error code, and second, we can build documentation for this error
>> code base on user-list thread/stackoverflow/other source.
>>
>> Any thoughts?
>>
>> [1] Mysql
>> https://dev.mysql.com/doc/refman/8.0/en/error-message-elements.html
>> [2] OracleDB https://docs.oracle.com/pls/db92/db92.error_search
>> [3] PostgreSQL https://www.postgresql.org/docs/10/errcodes-appendix.html
>>
>> Thanks,
>> Mike.
>>
>
Re: Error Codes
Posted by Michael Cherkasov <mi...@gmail.com>.
Hi Ilya,
It's about logs only, I don't think we need this at the API level. Error
codes will make the solutions more searchable.
Plus we can build troubleshooting guides based on it, it will help us
gather information from user list and StackOverflow.
Even a solution for trivial cases will be helpful, once I was requested to
join the call late evening because ignite failed to copy WAL file and there
just was no space on the disk.
While the error was obvious for me, it's not obvious for all users.
Let's start from something simple, just assign error codes to
absolutely all exceptions first. So next year or two user list will full of
error codes and solutions for them.
Might be it's a change for Ignite 3.0? @Val, I think you can help with this
question.
Any thoughts/comments?
Thanks,
Mike.
сб, 2 янв. 2021 г. в 12:18, Ilya Kasnacheev <il...@gmail.com>:
> Hello!
>
> I don't think there's a direct link between an exception thrown in depths
> of Ignite code, and specific error which may be reported to user.
>
> A notorious example is CorruptedTreeException which is known to be thrown
> due to incorrect field type in binary object or bad SQL cast. So we could
> document it "If you get IGN13 error this means your persistence is
> corrupted beyond repair. This, or you have a typo in your SQL." - of course
> it will not help anyone.
>
> This means we can't get to the desired result by application of 1.
>
> There's got to be a different plan. First of all, we need to decide what's
> our target. Is it log, or is it API?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 1 янв. 2021 г. в 02:07, Michael Cherkasov <michael.cherkasov@gmail.com
> >:
>
>> Hi folks,
>>
>> I was thinking how we can simplify Ignite clusters troubleshooting and
>> the best of course if the cluster can do self-healing, like transaction
>> cancellation if tx blocks exchange or note restart on OOM error. However,
>> sometimes those mechanisms don't work well or user interaction is required.
>> Not all errors are obvious for users and it's not clear what actions
>> required to restore the cluster.
>> If you google exceptions or error messages and the results can be
>> ambiguous and not certain because different errors can have similar
>> exceptions and you need to analyze stack trace to distinguish them. So
>> googling isn't a straight and easy process in this case.
>> Almost all major DBs have error codes[1][2][3]
>> Let's do the same for Ignite, error codes easy to google, so user/dev
>> list will be significantly more useful. We can have documentation with an
>> error code registry and solutions for the errors.
>>
>> To implement this we need to do the following:
>> 1. all error messages/exceptions must have a unique error code(so, all
>> new PR must NOT be accepted if any exceptions/errors don't have error
>> codes.)
>> 2. to avoid error code duplication, all error codes will be stored as
>> files under some folder.
>> 3. those files can be a source of documentation for this error code.
>>
>> All this files can be empty, but futher, if exception will apper on user
>> list and someone will find solution, first, other people can easialy google
>> it by error code, and second, we can build documentation for this error
>> code base on user-list thread/stackoverflow/other source.
>>
>> Any thoughts?
>>
>> [1] Mysql
>> https://dev.mysql.com/doc/refman/8.0/en/error-message-elements.html
>> [2] OracleDB https://docs.oracle.com/pls/db92/db92.error_search
>> [3] PostgreSQL https://www.postgresql.org/docs/10/errcodes-appendix.html
>>
>> Thanks,
>> Mike.
>>
>
Re: Error Codes
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
I don't think there's a direct link between an exception thrown in depths
of Ignite code, and specific error which may be reported to user.
A notorious example is CorruptedTreeException which is known to be thrown
due to incorrect field type in binary object or bad SQL cast. So we could
document it "If you get IGN13 error this means your persistence is
corrupted beyond repair. This, or you have a typo in your SQL." - of course
it will not help anyone.
This means we can't get to the desired result by application of 1.
There's got to be a different plan. First of all, we need to decide what's
our target. Is it log, or is it API?
Regards,
--
Ilya Kasnacheev
пт, 1 янв. 2021 г. в 02:07, Michael Cherkasov <mi...@gmail.com>:
> Hi folks,
>
> I was thinking how we can simplify Ignite clusters troubleshooting and the
> best of course if the cluster can do self-healing, like transaction
> cancellation if tx blocks exchange or note restart on OOM error. However,
> sometimes those mechanisms don't work well or user interaction is required.
> Not all errors are obvious for users and it's not clear what actions
> required to restore the cluster.
> If you google exceptions or error messages and the results can be
> ambiguous and not certain because different errors can have similar
> exceptions and you need to analyze stack trace to distinguish them. So
> googling isn't a straight and easy process in this case.
> Almost all major DBs have error codes[1][2][3]
> Let's do the same for Ignite, error codes easy to google, so user/dev list
> will be significantly more useful. We can have documentation with an error
> code registry and solutions for the errors.
>
> To implement this we need to do the following:
> 1. all error messages/exceptions must have a unique error code(so, all new
> PR must NOT be accepted if any exceptions/errors don't have error codes.)
> 2. to avoid error code duplication, all error codes will be stored as
> files under some folder.
> 3. those files can be a source of documentation for this error code.
>
> All this files can be empty, but futher, if exception will apper on user
> list and someone will find solution, first, other people can easialy google
> it by error code, and second, we can build documentation for this error
> code base on user-list thread/stackoverflow/other source.
>
> Any thoughts?
>
> [1] Mysql
> https://dev.mysql.com/doc/refman/8.0/en/error-message-elements.html
> [2] OracleDB https://docs.oracle.com/pls/db92/db92.error_search
> [3] PostgreSQL https://www.postgresql.org/docs/10/errcodes-appendix.html
>
> Thanks,
> Mike.
>
Re: Error Codes
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
I don't think there's a direct link between an exception thrown in depths
of Ignite code, and specific error which may be reported to user.
A notorious example is CorruptedTreeException which is known to be thrown
due to incorrect field type in binary object or bad SQL cast. So we could
document it "If you get IGN13 error this means your persistence is
corrupted beyond repair. This, or you have a typo in your SQL." - of course
it will not help anyone.
This means we can't get to the desired result by application of 1.
There's got to be a different plan. First of all, we need to decide what's
our target. Is it log, or is it API?
Regards,
--
Ilya Kasnacheev
пт, 1 янв. 2021 г. в 02:07, Michael Cherkasov <mi...@gmail.com>:
> Hi folks,
>
> I was thinking how we can simplify Ignite clusters troubleshooting and the
> best of course if the cluster can do self-healing, like transaction
> cancellation if tx blocks exchange or note restart on OOM error. However,
> sometimes those mechanisms don't work well or user interaction is required.
> Not all errors are obvious for users and it's not clear what actions
> required to restore the cluster.
> If you google exceptions or error messages and the results can be
> ambiguous and not certain because different errors can have similar
> exceptions and you need to analyze stack trace to distinguish them. So
> googling isn't a straight and easy process in this case.
> Almost all major DBs have error codes[1][2][3]
> Let's do the same for Ignite, error codes easy to google, so user/dev list
> will be significantly more useful. We can have documentation with an error
> code registry and solutions for the errors.
>
> To implement this we need to do the following:
> 1. all error messages/exceptions must have a unique error code(so, all new
> PR must NOT be accepted if any exceptions/errors don't have error codes.)
> 2. to avoid error code duplication, all error codes will be stored as
> files under some folder.
> 3. those files can be a source of documentation for this error code.
>
> All this files can be empty, but futher, if exception will apper on user
> list and someone will find solution, first, other people can easialy google
> it by error code, and second, we can build documentation for this error
> code base on user-list thread/stackoverflow/other source.
>
> Any thoughts?
>
> [1] Mysql
> https://dev.mysql.com/doc/refman/8.0/en/error-message-elements.html
> [2] OracleDB https://docs.oracle.com/pls/db92/db92.error_search
> [3] PostgreSQL https://www.postgresql.org/docs/10/errcodes-appendix.html
>
> Thanks,
> Mike.
>