History and future of C++11's <system_error>

[charleyb123 .]

I am researching discussions-and-decisions that brought C++11's <system_error>, and in particular:

  *- std::error_category

  *- std::error_code

  *- std::error_condition

I've read very carefully the discussion of evolution and rationale in the (slightly dated) blog series at:

  *- http://blog.think-async.com/2010/04/system-error-support-in-c0x-part-1.html

Are there other resources/discussions to help my understanding?  (I see very little information on the web.)

IMHO, <system_error> is a little-known and little-understood "gem" in C++11.  As a community, it seems like we gain great benefit from a Highly Practical and Standardized (Common-Convention) way to handle error scenarios across modules and codebases.

Regarding evolutionary changes going forward, I see value in considering:

(a) constexpr

(b) instance-specific "error_code" values (e.g., with instance-specific field-values)

(c) internationalization

(d) expanded articulation of "rationale" and recognized use-patterns

These would make integration with logging frameworks and template meta-programming libraries *far* easier.

With 'constexpr' done properly, perhaps it could even be the basis for user-friendly compile-time (error/warning) messages through the meta-programming library author (and not the compiler-vendor, as it is today).

Any suggested links or discussions on the Committee's thoughts regarding std::error_category/code/condition?

--charley

[Victor Dyachenko]

This question is unaswered since 2011: http://stackoverflow.com/questions/7542822/should-i-use-system-category-or-generic-category-for-errno-on-unix
No body knows (including Chris Kohlhoff???) how to use this stuff

[nialldo...@gmail.com]

Here is a stackoverflow question where it is answered: https://stackoverflow.com/questions/28746372/system-error-categories-and-standard-system-error-codes

[Victor Dyachenko]

On Saturday, October 15, 2016 at 9:58:21 PM UTC+3, nialldo...@gmail.com wrote:

Here is a stackoverflow question where it is answered: https://stackoverflow.com/questions/28746372/system-error-categories-and-standard-system-error-codes

This link provides some useful research but not the answer

[nialldo...@gmail.com]

No, it tells you the answer, as indeed does the C++ standard text. The question was:

"However, what should be done on Unix-like systems, where errno values are the errors returned by the operating system? Should I use system_category() (which would be wrong on non-Unix-like systems, needing an #ifdef), or should I use generic_category() (which would be wrong on Unix-like systems for non-standard errno values)?"

The answer given in my link is "use system_category for all errors returned by the OS on all platforms. Only use generic category on Windows for the POSIX emulation functions in the MSVCRT". I think I even gave a quick map of error number spaces in my answer, pointing out that on POSIX every implementation I've seen considers generic_category and system_category to be the same, even though strictly speaking generic_category should not be able to understand non-POSIX error codes.

Back to the original question by Charley: I am not aware of any publicly available notes, however seeing as <system_error> has evolved in lock step with <exception> such that all exceptions throwable by the standard library have a corresponding lossless representation in std::error_code, somebody in the committee is clearly on the ball on this.

Niall

[Victor Dyachenko]

Ok. One simple task. Suppose we have some HTTP C++ library and want to detect situations when the peer unexpectedly closes the channel. On POSIX systems we will have EPIPE on write()/send().

try
{
    send(http::request(...));
}
catch(const std::system_error &ex)
{
    if(ex.code() == std::errc::broken_pipe)
    {
        // Do something
    }
}

Does it look reasonable? Yes, for me. But it doesn't work in practice!

If the HTTP-library uses Asio (even standalone version) you have to check the error condition against the library-specific asio::error::broken_pipe inspite of the error came from the OS.

[nialldo...@gmail.com]

Remember if you're accessing ec.code(), you're doing something wrong 99% of the time.

Try comparing ec directly to std::errc::broken_pipe. asio::error is an enum inside the system_category error number space. It ought to work, depending on whether your STL implementer has mapped the win32 error code ERROR_BROKEN_PIPE to std::errc::broken_pipe (I would have thought that mapping pretty obvious, but there are known incorrect win32 to POSIX error code maps in MSVCRT which cannot be fixed for backwards compatibility reasons).

If directly comparing an error_code returned by ASIO directly to std::errc::broken_pipe doesn't work, log it as a bug with ASIO at https://github.com/chriskohlhoff/asio/issues. Chris is pretty good at fixing issues reported.

Niall

[Victor Dyachenko]

On Monday, October 17, 2016 at 2:20:36 PM UTC+3, nialldo...@gmail.com wrote:

Remember if you're accessing ec.code(), you're doing something wrong 99% of the time.

Try comparing ec directly to std::errc::broken_pipe.

What? Which "ec"? Do you mean "ex" - compare exception with error condition?
 

asio::error is an enum inside the system_category error number space. It ought to work, depending on whether your STL implementer has mapped the win32 error code ERROR_BROKEN_PIPE to std::errc::broken_pipe (I would have thought that mapping pretty obvious, but there are known incorrect win32 to POSIX error code maps in MSVCRT which cannot be fixed for backwards compatibility reasons).

I don't use MSVC. It's Linux.

[Victor Dyachenko]

On Monday, October 17, 2016 at 2:20:36 PM UTC+3, nialldo...@gmail.com wrote:

Try comparing ec directly to std::errc::broken_pipe. asio::error is an enum inside the system_category error number space.

Wrong. It's asio::error::system_category not std::system_category

[nialldo...@gmail.com]

On Monday, October 17, 2016 at 1:34:31 PM UTC+1, Victor Dyachenko wrote:

On Monday, October 17, 2016 at 2:20:36 PM UTC+3, nialldo...@gmail.com wrote:

Remember if you're accessing ec.code(), you're doing something wrong 99% of the time.

Try comparing ec directly to std::errc::broken_pipe.

What? Which "ec"? Do you mean "ex" - compare exception with error condition?
 

It's pretty clear from https://github.com/chriskohlhoff/asio/blob/41cb2faa19959f7ae43d60aa41ee245db44f817f/asio/include/asio/impl/error_code.ipp that ASIO intends asio::error to map onto std::errc.

If it's not working for you, instead of arguing with me here when I am not the author of that library, please go file a bug with ASIO's issue tracker. Chris also had a big hand in designing the original system_error, he's the right man to be talked to about all this stuff (Charley included BTW).

Niall

[Victor Dyachenko]

On Monday, October 17, 2016 at 2:20:36 PM UTC+3, nialldo...@gmail.com wrote:

On Monday, October 17, 2016 at 9:15:55 AM UTC+1, Victor Dyachenko wrote:

Ok. One simple task. Suppose we have some HTTP C++ library and want to detect situations when the peer unexpectedly closes the channel. On POSIX systems we will have EPIPE on write()/send().

try
{
    send(http::request(...));
}
catch(const std::system_error &ex)
{
    if(ex.code() == std::errc::broken_pipe)
    {
        // Do something
    }
}

Does it look reasonable? Yes, for me. But it doesn't work in practice!

If the HTTP-library uses Asio (even standalone version) you have to check the error condition against the library-specific asio::error::broken_pipe inspite of the error came from the OS.

Remember if you're accessing ec.code(), you're doing something wrong 99% of the time.

 Still, can you, PLEASE, elaborate what is wrong with my code snippet and how it must be done right?