You can of course create your own enums for whatever error domain you like.  You can even forget about enums and create any set of values to represent errors - since std::error can hold any arbitrary data.

The point of the standard enumerated ones I proposed is just for mapping to standard C++ exceptions.  (For the purpose of weak-equality comparison with an std::error that holds an std::exception_ptr).  

My argument in the paper is that we should at least create a set of generic enums that map closely to standard exceptions.  Note the current situation is already much WORSE than this - since we only have generic enums that map to POSIX codes, which are more intended for operating system errors and don't map very well to standard C++ exception types.

On Sat, May 16, 2020 at 3:35 AM Dmitry <dimanne@gmail.com> 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@lists.isocpp.org> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> wrote:
Do you need help publishing this in a mailing?

On Tue, May 12, 2020, 06:00 Charles Salvia via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
I've implemented std::error, meeting the requirements laid out in [P1028], 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.

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


--
Dmitry
Sent from gmail