Just a couple of additional thoughts.

If I designed it, I would separate these two very different concerns:

   - Programmatic reaction to an error. The only known for me is retries,
   hence, there should be a flag whether a particular error is retry-able or
   not. (Almost) none of the remaining errors can be fixed
   *programmatically*. (If you know that an argument causes value_too_large
   error, and you know how to fix the argument, you will probably fix it
   before calling a function, not after it reported value_too_large).
   - Explaining what and why went wrong. And this mechanism requires much
   more resources. Sometimes you need to capture some context (arguments,
   variable, state), sometimes you need to compose a message/string explaining
   what went wrong and so on...


On Sat, May 16, 2020 at 8:35 AM Dmitry <dimanne_at_[hidden]> wrote:

> That is a very interesting topic, actually.
> I might be totally wrong, but to me it is impossible to make an (1)
> actionable/useful for all, (2) extensible and (3) fast/simple mechanism for
> enumerating errors.
> Correct me if I am wrong, but it looks like the current approach just
>
> - hardcodes a couple of errors/domains, which makes it not extensible
> (I cannot add my own, specific and useful to my application errors and/or
> domains)
> - and makes them as generic as possible, which makes them too vague
> and obscure to be actionable (for example, invalid_argument - what am I
> supposed to do when receive this? Randomly change all arguments of a
> function to something else in the hope it helps? What is the point of
> having this error at all?).
>
>
> On Thu, May 14, 2020 at 1:20 AM Charles Salvia via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Thanks again for your help. Here's the re-formatted version:
>>
>> http://charles-salvia.github.io/D2170R0.html
>>
>> On Wed, May 13, 2020 at 4:21 AM Gašper Ažman <gasper.azman_at_[hidden]>
>> wrote:
>>
>>> D2170R0 is yours :)
>>>
>>> The next mailing is May 15th at 2pm UTC, so make sure you hit that.
>>> Sorry for the rush.
>>>
>>> Gašper
>>>
>>> On Wed, May 13, 2020 at 9:09 AM Gašper Ažman <gasper.azman_at_[hidden]>
>>> wrote:
>>>
>>>> Look at mpark/wg21 on GitHub.
>>>>
>>>> It's not the only way to format documents, but it helps. A paper has a
>>>> particular structure you should follow, but since yours is not a proposal,
>>>> you can skip the proposed wording.
>>>>
>>>> Once your paper is "in shape" I'll upload it to the tracker. I'll get
>>>> you a paper number later today.
>>>>
>>>> G
>>>>
>>>> On Tue, May 12, 2020, 15:35 Charles Salvia <charles.a.salvia_at_[hidden]>
>>>> wrote:
>>>>
>>>>> Yes, thank you, that would be great. What is the process for
>>>>> publishing in a mailing?
>>>>>
>>>>> On Tue, May 12, 2020 at 2:41 AM Gašper Ažman <gasper.azman_at_[hidden]>
>>>>> wrote:
>>>>>
>>>>>> Do you need help publishing this in a mailing?
>>>>>>
>>>>>> On Tue, May 12, 2020, 06:00 Charles Salvia via Std-Proposals <
>>>>>> std-proposals_at_[hidden]> wrote:
>>>>>>
>>>>>>> I've implemented std::error, meeting the requirements laid out in [
>>>>>>> P1028
>>>>>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1028r3.pdf>],
>>>>>>> and based on this experience, have written up a paper outlining various
>>>>>>> design decisions and concerns that came up during the implementation,
>>>>>>> particularly with regard to how std::error might map to existing error
>>>>>>> mechanisms (dynamic exceptions, std::error_code).
>>>>>>>
>>>>>>> This is not a formal proposal right now. It is intended simply to
>>>>>>> further discussion around the design, requirements and implementation
>>>>>>> details of some future std::error specification.
>>>>>>>
>>>>>>> https://charles-salvia.github.io/std_error_feedback.html
>>>>>>> --
>>>>>>> Std-Proposals mailing list
>>>>>>> Std-Proposals_at_[hidden]
>>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>>>
>>>>>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
>
> --
> Dmitry
> *Sent from gmail*
>

-- 
Dmitry
*Sent from gmail*