Ivan, thanks for the prepared document! I've left a couple questions.
On Wed, Mar 23, 2022 at 10:49 AM Ivan Bessonov
wrote:
> Hi everyone,
>
> I'd like to continue the discussion. I created IEP with the attempt to
> summarize
> all the information above, you can find it here [1]. What do you
Hi everyone,
I'd like to continue the discussion. I created IEP with the attempt to
summarize
all the information above, you can find it here [1]. What do you think?
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-84%3A+Error+handling
ср, 21 апр. 2021 г. в 20:46, Alexei Scherbakov :
Alexei,
I think it's ok to do error conversion if it makes sense, but better to
preserve the root cause whenever possible.
Another way to solve the described scenario is to introduce something like
checked IgniteRetryAgainException, which forces the user to retry or ignore
it.
It's difficult to
Aleksei,
> The method should always report root cause, in your example it will be
> B-, no matter which module API is called
I may be wrong, but I doubt this will be usable for an end-user. Let's
imagine that the same root exception was raised in different contexts
resulting in two outcomes.
Andrey,
I've already proposed the similar string representation in the very first
message of the topic.
ср, 21 апр. 2021 г. в 12:31, Andrey Mashenkov :
> Alexey,
>
> As I understand, you suggest ErrorScope enum for easier analysis and it
> will be a part of a error code.
> But what about String
Alexey,
As I understand, you suggest ErrorScope enum for easier analysis and it
will be a part of a error code.
But what about String representation?
I think we should use a common prefix for error codes in error messages.
Such codes will be more searchable and as a bonus, vendor-specific.
I've create the ticket for implementing this [1]
[1] https://issues.apache.org/jira/browse/IGNITE-14611
пт, 16 апр. 2021 г. в 16:30, Alexei Scherbakov :
>
>
> чт, 15 апр. 2021 г. в 18:21, Andrey Mashenkov >:
>
>> Hi Alexey,
>> I like the idea.
>>
>> 1.
>>
>> > TBL-0001 is a *string
чт, 15 апр. 2021 г. в 18:21, Andrey Mashenkov :
> Hi Alexey,
> I like the idea.
>
> 1.
>
> > TBL-0001 is a *string representation* of the error. It is built from 2
> > byte scope id (mapped to name TBL) and 2 byte number (0001). Both
> > internally packed in int. No any kind of parsing will be
Hi Alexey,
I like the idea.
1.
> TBL-0001 is a *string representation* of the error. It is built from 2
> byte scope id (mapped to name TBL) and 2 byte number (0001). Both
> internally packed in int. No any kind of parsing will be necessary to read
> scope/category.
I think Alexey mean if it
чт, 15 апр. 2021 г. в 14:26, Ilya Kasnacheev :
> Hello!
>
> > All public methods throw only unchecked
> org.apache.ignite.lang.IgniteException containing aforementioned fields.
> > Each public method must have a section in the javadoc with a list of all
> possible error codes for this method.
>
>
Hello!
> All public methods throw only unchecked
org.apache.ignite.lang.IgniteException containing aforementioned fields.
> Each public method must have a section in the javadoc with a list of all
possible error codes for this method.
I don't think this is feasible at all.
Imagine javadoc for
Hi Alexei,
> Each public method *must *have a section in the javadoc with a list of
all possible error codes for this method.
I consider it is redundant, because any public exception can be thrown from
public API.
If it not happens today, it may change tomorrow: one will be removed,
another one
Alexey,
ср, 14 апр. 2021 г. в 01:52, Alexey Kukushkin :
> Just some points looking questionable to me, although I realize the error
> handling style may be very opinionated:
>
>- Would it make sense splitting the proposed composite error code
>(TBL-0001) into separate numeric code (0001)
Just some points looking questionable to me, although I realize the error
handling style may be very opinionated:
- Would it make sense splitting the proposed composite error code
(TBL-0001) into separate numeric code (0001) and scope/category ("TBL") to
avoid parsing the code when an
14 matches
Mail list logo
